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The  demand  for  software  products  has  grown,  but  the 
number  of  quality  programmers  has  not  kept  pace. 
Therefore,  programmer  prodcutivity  aas  become  a  major  area 
of  discussion  throughout  the  software  development  industry. 
This  paper  examines  tha  various  measures  discussed  in  the 
literature  and  used  in  selected  corporations  which  develop 
software.  It  presents  several  methods  for  measuring 
programmer  productivity.  Included  ia  the  discussion  are  the 
salient  points  where  managsrs  must  ievote  special  attention 
if  they  are  to  use  programmer  productivity  measures  effec- 
tively. This  paper  is  part  of  a  group  of  papers  which 
together  provide  recoam=a dations  to  the  Fleet  Material 
Support  Office  (FMSO)  to  enhance  its  software  development 
organization. 
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In  the  past  two  decades,  as  computer  hardware  costs  have 
fallen  and  software  costs  have  risen,  +-here  has  been  an 
increasing  interest  in  programmer  productivity.  This 
interest  has  become  particularly  intense  during  the  last 
decade  as  the  general  purpose  computer  market  has  flour- 
ished. Customers  are  becoming  much  more  aware  of  the 
flexibility  that  different  software  packages  provide  to 
computer  hardware.  They,  therefore,  are  demanding  more  and 
more  software  products  to  upgrade  existing  hardware  facili- 
ties. Rithington  [Ref.  1  ]  of  Arthir  D.  Little  Inc.,  a 
Cambridge  (Mass.)  consulting  firm,  states  that  the  throt- 
tling factor  in  the  evolution  of  the  data  processing 
industry  is  the  pace  of  software  development.  Revenues  in 
the  data  processing  industry  are  expected  to  reach  395 
billion  by  1984  but  have  the  potential  to  reach  $125  billion 
if  the  software  development  constraint  did  not  exist.  This 
software  demand  has  precipitated  a  large  demand  for  program- 
mers. But  programmers,  especially  stilled  ones,  are  hard  to 
find  and  take  time  to  train.  Since  there  has  been  such  an 
astronomical  growth  in  the  computer  software  industry, 
finding  sufficient  numbers  of  well  trained  and  experienced 
programmers  is  prohibitively  difficult.  [Ref.  2],  According 
to  Digital  Equipment  Corporation  * Bef .  3],  the  biggest 
problem  is  identifying  the  few  gnoi  programmers.  Of  the 
many  applicants  they  receive,  most  are  not  capable  of 
writing  sophisicated  software.  Consequently ,  software 
developers  are  turning  towards  increasing  the  productivity 
of  programmers  in  an  attempt  to  keep  pace  with  the  demand 
for  current  and  future  software  design  needs. 


There  have  been  a  number  of  papers  writtsn  discussing 
pro ductivity.  Some  discuss  deterainants  of  programming 
productivity  [Ref.  2 ],  others  provide  tools  (Ref.  4],  which 
purport  to  improve  productivity.  Interestingly,  few  of 
these  studies  discuss  or  aake  reference  to  others  who  have 
discussed  how  to  actually  measure  this  productivity.  The 
philosophical  approach  foe  many  years  was  that  programming 
was  an  art.  This  made  it  virtually  impossible  to  measure, 
for  it  would  be  similar  to  measuring  the  progress  or  produc- 
tivity of  a  Picasso  or  Michelangelo  as  he  was  painting  or 
sculpting.  Obviously,  there  is  10  way  to  leasure  the 
progress  of  art  aside  froa  personal  opinion.  This,  however, 
is  not  acceptable  in  an  industry  based  on  the  profit  motive. 
In  the  late  1 9 60 » s  the  tera  "Software  Engineering"  was 
coined  and  with  it  came  a  number  of  ideas  that  served  to 
pull  programming  out  of  tha  world  of  art  and  into  the  world 
of  the  engineer,  a  woeLd  where  neasurement  is  of  vital 
importance.  Software  development  «a=  shown  to  be  an  area 
that  required  discipline  and  a  process-oriented  approach 
[Ref.  5]. 

Software  engineering  has  grown  through  the  1970  's  to 
virtually  become  the  rule  for  the  management  of  programming. 
It  has  led  to  the  development  of  new  strategies  for  software 
development.  These  strategies,  top-down  design,  bottom-up 
design,  structured  prgraaming,  moiular  decomposition  and 
metaprogramming ,  have  provided  a  better  foundation  from 
which  software  developers  can  attempt  to  meet  the  growing 
ieaar.d  fcr  software  products.  Although  these  development 
techniques  have  made  software  development  easier  and  helpei 
tc  control  the  cost  growth,  they  have  had  little  impact  on 
productivity  measurement. 

To  discuss  the  measuring  of  software  development  or 
programming  productivity,  one  must  first  determine  what  the 
product  is.     From  the  first   day  of  programming   until  the 


present,  the  predominant  product  of  discussion  has  been  the 
"line  of  code"  (LOC) .  This  is  tha  product  on  which  nearly 
all  research  and  the  database  information  are  based.  If  one 
were  a  construction  engineer  one  would  not  discuss  a 
building  or  brid  ce  based  on  the  number  of  bricks  and  girders 
used.  Instead,  rooms  or  floors  or  spans  might  be  much  more 
appropriate.  These  items  are  integral  but  separately 
measureable  components  of  the  final  product.  So  whyr 
rhetorically,  do  researchers  and  data  base  information 
collectors  continue  to  insist  on  L03  measures  instead  of  au 
integral  and  separately  measureable  and  meaningful  component 
of  software  engineering?  This  not  a  question  for  this  paper 
to  answer  but  one  for  the  reader  to  consider  when  planning 
his  own  research  or  data  base  collection. 

The  Fleet  Material  Support  Offisa  (FMSO)  is  experiencing 
the  same  Droblems  as  the  rest  of  the  software  indusrty.  It 
is  faced  with  a  huge  demand  for  quality  software  from  the 
organizations  it  is  tasked  to  support.  The  tasking  of  the 
pas*  five  years  is  shown  in  Figure  1.1  below.  These  figures 
are  only  for  the  Central  Design  Agency,  the  primary  mission 
of  FMSO.  The  figures  show  an  increase  in  FMSO  maintained 
programs  of  75.4  percent  in  this  short  period.  These 
figures  are  expected  to  continue  to  rise  at  a  significant 
rare  as  the  Navy  continues  to  automate  more  and  more  func- 
tions. Another  problem  facing  FMSO  is  the  salaries  of  the 
programmers.  According  to  Business  ifeek  [  Ref .  5]  programmer 
salaries  are  rising  at  a  rate  of  15  percent  annually  and 
salaries  for  top  systems  analysts  can  reach  $50,000  a  year. 
This  places  an  extreme  burden  on  the  personnel  department  to 
acquire  top  personnel  when  hiring  new  programmers  and 
systems  analysts.  Thi  productivity  issue  becomes 
increasingly  critical  for  FMSO  in  the  light  of  the  hiring 
freeze  imposed  during  the  Carter  administration  and  the 
drive  to  reduce  the  cost  of  government  in  ~he  present  Reagan 
administration. 
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Figure  1.1    FMS3  Program  Library  Growth. 

This  paper  attempts  to  presant  a  number  of  issues 
related  to  the  measuring  of  programmer  productivity.  It 
will  show  that  there  are  a  other  factors  that  impact  on  how 
on2  interprets  the  productivity  figures.  The  manager  needs 
to  realize  there  are  several  different  levels  of  the  organi- 
zation, each  with  its  :wn  product  or  set  of  products. 
Therefore,  each  level  has  a  productivity  rating  for  which  it 
must  be  responsible.  In  fact,  the  reader  should  note  that 
the  programmer  is  not  the  predominant  link  in  the  output  of 
a  programming  project.  lie  reguirsments  of  the  Department 
cf  Defense  and  conscientious  software  developers  throughout 
the  industry  has  placed  increasing  importance  on  the  relia- 
bility and  maintainability  of  software.  This  new  emphasis 
has  produced  a  whole  array  of  corresponding  products  which 
must  be  accounted  for  and  new  productivity  levels  which  must 
be  examined. 
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II.     WHQSE    PRODgCT   IS    BEING    MEASURED? 

When  discussing  productivity,  before  one  can  consider 
who  to  measure,  one  must  first  determine  what  the  product  is 
and  then  who  makes  the  product.  Without  a  rational  visuali- 
zation of  the  product  it  is  unintelligent  to  discuss  the 
ability  of  a  person's,  group's  or  machine's  ability  to 
deliver      tKat   product.  Depending   apon      the     level   of      the 

organization  at  which  one  looks  there  will  be  a  variety  of 
goals,  objectives  and  products.  Both  Kiser  [Ref.  7,  p.  244] 
and  the  IEEE  Workshop  d n  Software  Productivity  [Ref.  8] 
address   this   important   issue. 

Where  the  IEEE  Workshop  focused  Dr.  the  general  area  of 
productivity,  Kiser  was  most  concerned  with  software  manage- 
ment productivity.  She  focused  on  the  idea  that  the  manager 
often  has  as  much  to  do  with  a  programmer ' s  productivity  as 
does  the  programmer  himself  or  his  tools.  This  is  a  nontri- 
viai      issue.  She      lookei      at      the      top      three      levels      of 


Figure   2.1        Kiser:    Levels    of  Note   ia    Software   Productivity. 

management,    shown  in    Figure    2.1     .      flany    managers    have    failed 
to      understand    why      their      people,         being    well-trained      and 
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provided  with  excellent  tools,  continue  to  produce  at  unsa- 
tisfactory levels.  Quite  often,  from  this  researcher's 
experience  and  the  ex peri a  nee  provided  by  Kisec,  the  poor 
production  levsi  is  caused  by  higher  level  managerial  poli- 
cies or  actions.  This  can  be  understandable  when  one 
examines  the  concerns  of  tie  various  nanagement  levels. 

At  the  corporate  lsvel,  top  management  is  usually 
concerned  with  profit  maximization  aad  market  share.  FMSO, 
being  part  of  the  public  sector,  d^es  not  have  this  parti- 
cular concern  but  there  are  comparabLe   goals  (  Figure  2.2  ) 


CENTRAL  DESIGN  AGENC?  (CDA) 
RETAIL  NAVY  5T0CK  FUND 
OPERATIONS  ANALYSIS 
SUPPLY  OPERATIONS  SaPPORT 
INTERNATIONAL  LOGISTICS 


Figure  2.2   FMSO  Major  Mission  Areas. 

which  are  fleet  support  aid  effective  management  of  their 
approximate  S3. 8  billion,  FY82,  procurement  authority.  When 
one  considers  the  impact  of  money  management  at  this  level 
it  is  understandable  that  concerns  for  indiviual  programmer 
productivities  can  get  lost.  The  interpretation  of  top 
level  management  polices  ay  lower  level  managers  can  also 
affect  productivity. 

At  the  middle  management  level,  managers  become 
concerned  with  specific  product  development  and  resource 
allocation.  For  FMSO,  in  its  primary  mission  area  as  a  CDA, 
management   is  concerned  i ith   allDcation   of  resources   to 
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UNIFORM  AUTOMATED  DATA  PROCESSING  SYSTEMS  (UADPS) 
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Level  U/III  Stock  Points 
Disk  Oriented  Supply  Systen  (DOSS) 

HEADQUARTERS  FINANCIAL  SYSTEMS 

MANAGEMENT  INFORMATION  SYSTEM  FDR  INTERNATIONAL 
LOGISTICS  -  (MI3IL) 

SPECIAL  DATA  PROCESSING  SYSTEMS  PROJECTS 
Reauisiticn  Material  Monitoring  and 

Expediting  (SMM5E) 
Trident 
Naval  Aviarion  Logistics  Command  Management 

Information  System  (NAL3DMIS) 
Naval  Automated  Transportation  Data  System 

(NATDS) 
Naval  Automated  r rans portaion  Documantation 

System  (NHVi)S) 
Resolicitation 


Figure  2.3    FMSO  CDA  Primary  Product  Areas. 

respective  product  areas  as  shown  in  Figure  2.3  below.  The 
allocation  of  the  resources  is  tempered  with  the  command 
goals  and  the  budget  provided  by  the  various  sponsors. 

The  first  lire  level  of  managemeit,  project  management, 
is  where  one  fLzsz  encouacers  the  edge  of  software  produc- 
tivity, the  area  with  which  this  paper  is  concerned.  Here 
the  project  manager  is  concerned  »ith  meeting  prescribed 
milestones  within  budget.  The  products  at  this  level  are 
ths  various  "deliverables",  such  as  functional  specifica- 
tions, conceptual  designs,  program  dssign,  test  plans,  etc., 
that  are  required  in  an  effectively  managed  project  with 
milestone  requirements.  These  are  the  products  one  must 
measure  against  their  respective  costs. 
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At  the  Una  level  itself  there  are  two  groups,  project 
teams  and  the  individuals  who  make  up  the  teams.  The  team 
must  be  measured  against  its  ability  to  deliver  integrated 
software  products.  The  individuals  must  be  measured  against 
their  ability  to  deliver  specific  portions  of  the  team 
assignment.  This  is  the  point  where  programmer  productivity 
is  discussed  by  most  researchers.  A  special  note  is 
required  at  this  point.  While  one  usually  assumes  that  the 
delivered  products  are  of  a  specific  quality,  this  seems  to 
be  missed  quite  often  when  discussing  programmer  products. 
The  idea  of  quality  in  the  product  must  always  be  consid- 
ered. A  person  who  can  deliver  five  programs  in  one  day 
that  are  incorrect  or  do  not  provids  consistent  results  is 
not  nearly  as  productive  as  one  who  delivers  one  product 
every  five  days  but  which  is  correct  and  easily  maintained. 
Very  few  productivity  measures  take  quality  into 
consideration,  as  will  be  shown  later. 

After  realizing  the  various  products  made  by  different 
levels  in  the  organization,  one  must  then  consider  who  is 
viewing  these  measures,  management  or  labor.  The  views  and 
concerns  of  each  are  usually  quite  different  unless  there 
has  been  a  considerable  amount  of  education  on  each  side. 

Management  must  understand  there  is  an  overhead  expense 
to  developing,  collecting  and  analyzing  productivity 
measures  which  must  be  -justified.  Intuitively,  one  must 
have  a  set  cf  measures  before  one  ran  determine  constant, 
"normal"  or  changing  productivity.  Mso  management  needs  to 
know  how  it  intends  to  use  these  measures.  The  IEEE 
[Raf.  8,  p.  3  41]  sees  four  major  uses  for  productivity 
measures:  1)  motivation;  2)  understanding;  3|  evaluation; 
ani  4)  management. 

Productivity  measures  can  be  used  for  motivational 
purposes  in  three  ways  which  provide  tangible  benefit. 
First,    researchers  [Ref.  9,]   have   shown   that  by   paying 
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attention  to  a  person  or  group,  performance  levels  of  that 
person  or  group  will  improve  or  change  to  what  the  observee 
perceives  as  expected  performance.  This  is  known  as  the 
B aw t home  Effect.  When  managers  take  the  time  to  do  produc- 
tivity studies  the  Hawthorne  Effect  may  occur,  albeit 
teiporarily.  Second  is  the  ability  to  focus  attention  on 
desired  behaviors,  events  and  objects  or  products.  The 
measures  selected  will  place  relative  importance  on  the 
araas  being  measured.  ? or  instates,  if  a  series  of 
measures  are  selected  which  include  speed  of  production  and 
maintainability  the  percaived  relation  between  them  by  tha 
programmer  will  determina  which  maasure  they  emphasize. 
That  perception  of  relative  importance  can  have  a  profound 
effect  en  the  final  product.  If  programmers  see  speed  being 
rewarded  or  emphasized  aore  than  maintainability,  the 
manager  should  expect  to  see  programs  produced  rapidly  but 
which  are  hard  to  understand  and  have  little  documentation. 
If  the  reverse  is  perceived,  then  the  manager  should  expect 
tc  see  longer  programming  timas  with  much  easier  to  under- 
stand and  better  documented  code.  The  third  motivating 
factor  occurs  through  feaiback  of  rasults.  The  effective 
feedback  of  productivity  aeasures  ran  lead  to  changes  in 
performance  in  several  ways.  Quita  often  performance  will 
improve  through  the  personal  prida  in  accomplishment  or 
competition  with  pcers.  Also  if  a  corresponding  and 
effective  rawards  and  panalty  system,  eithsr  formal  or 
informal,  exists,  per  foe  mar.ee  normally  will  follow  tha 
system  correspondingly. 

Second,  productivity  measursmants  help  managers  to 
understand  the  factors  unlarlying  productivity.  Measurement 
is  fundamental  to  scienca  in  that  it  forces  managers  and 
researchers  to  conceptualize  the  ar  =  a  under  study.  Using 
various  concepts  will  determine  which  measuras  to  use  as 
managers  continue  to   try  to  model  tia   environment  in  which 
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they  operate.  Failure  to  develop  a  model  will  hinder 
managers  in  improving  performance  and  will  keep  software 
development  an  art  instead  of  a 'science. 

Third,  productivity  measures  help  managers  evaluate 
performance  because  they  quantify  performance.  It  is  easier 
to  evaluate  performance  over  time  within  a  single  group  or 
organization  because  the  aeasures  remain  constant.  It  is 
also  very  important  to  track  performance  so  that  proper 
feedback  to  personnel  can  be  provided.  It  is  also  important 
to  evaluate  between  groups  to  see  how  one  stands  against,  an 
industry  average.  This  has  proven  to  be  particularly  diffi- 
cult for  software  developers.  Fe*  groups  use  the  same 
measures.  Those  that  use  similar  sounding  measures  often 
have  significantly  different  definitions  for  the  individual 
parts  of  the  measure.  LD" ,  which  will  be  discussed  later, 
is  a  most  common  area  of  disagreement.  Nevertheless,  it  is 
important  for  each  organization  to  establish  a  baseline  and 
to  build  a  database  of  information.  This  information  can 
than  be  used  for  measuring  the  evolution  of  methodologies 
and  technologies  used  in  software  development. 

Fourth,  productivity  measurement  imposes  a  managerial 
discipline.  Normally  managers  are  concerned  with  tracking 
progress  against,  a  scheduLe  and  budget. The  consistent  use 
and  taking  of  measurements  can  be  extremely  helpful  in 
making  projections  of  progress  against  schedules  and 
budgets.  The  manager  must  remember  that  a  productivity 
measure  is  only  a  snapshot.  It  must  be  analyzed  in  relation 
to  its  environment.  In  particular,  managers  must  realize 
the  difference  in  the  learning  curves  of  various  projects. 
A  "first-of- its-kind"  project  will  have  a  much  different 
learning  curve  than  a  simple  modification  to  a  generic 
project.  The  productivity  rates  will  normally  change 
proportionally  to  the  learning  curve. 


15 


The  manager's  need  for  measures  and  his  goals  can  differ 
significantly  frcm  those  of  the  workforce.  Management  often 
wants  to  use  the  measures  to  identify  exceptional  perform- 
mers  or  those  who  need  adled  training. 

The  workforce,  however,  may  view  the  measures  as  a  way 
to  generate  either  more  products  from  the  same  work  effort 
or  to  generate  the  same  number  of  products  from  a  reduced 
workforce.  When  the  workforce  sees  the  second  side  there 
can  be  severe  implications,  particularly  if  they  are 
organized. 

The  workforce  will  rapidly  wonier  what  taeir  benefits 
will  be  from  all  this  new  attention.  Will  the  measures  lead 
tc  more  money  for  the  same  hours,  the  same  money  for  less 
hours  for  the  good  pecformmers  ani/or  lost  jobs  for  the 
poorer  ones?  In  an  effort  at  job  preservation,  productivity 
may  fall  or  stagnate  at  a  predetermined  level.  This 
researcher  has  seen  deliberate  productivity  stagnation  by 
bricklayers,  both  in  the  housing  and  steel  industries,  and 
by  electricians  working  for  a  telephone  company,  all  at  well 
below  reasonable  levels  of  capability.  For  one  to  think 
that  programmers  and  their  industry  would  not  tend  to  act  in 
a  similar  fashion  is  to  approach  this  area  with  tunnel 
vision.  This  may  become  a  primary  concern  for  FMSO  where 
soae  of  their  government  employees  lold  specific  3S  ratings 
and  incomes  based  on  the  number  of  personnel  they  manage. 
Conmand  level  management  aust  take  care  in  the  introduction 
cf  -he  productivity  metrics  so  that  personnel  in  these  3S 
ratings  do  not  feel  that  their  jobs  or  ratings  are  in 
jeopardy  if  there  is  significant  increase  in  productivity 
which  leads  to  a  reduction  in  force  (RIF) . 
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III.  WHAJ?  IS  THE  PR3DUCT? 

This  researcher  has  determined  that  the  predominant 
measure  of  programmer  productivity  is  the  quantity  of  lines 
of  code  written.  This  leids  to  several  interesting  conclu- 
sions. First,  the  programmer  only  writes  deliverable  code. 
Second,  the  programmer  is  the  single  dominant  entity  in 
software  development.  Aid  third,  there  are  no  other  rele- 
vant products  or  by-products  in  i  software  development 
project.  Anyone  who  has  the  opportunity  to  study  or  to 
work  in  the  software  development  arsna  realizes  the  fallacy 
of  these  conclusions.  Programmers  do  considerably  more  than 
write  deliverable  code.  There  are  many  other  people 
involved,  each  adding  important  contributions  to  the 
project.   There  are  several  equally  important  products. 

Frcm  the  previous  chapter  it  was  noted  that  there  are 
many  levels  of  an  organization  whose  productivity  should  be 
measured.  These  involved  in  software  development  realize 
that  various  levels  of  tie  organization  make  contributions 
to  the  various  products  of  each  project.  This  chapter  will 
look  at  the  different  products  that  this  researcher  feels 
are  relevant  to  the  measure  of  software  development  produc- 
tivity. This  discussiDi  will  begin  with  middle  level 
management  and  work  towards  the  individual.  As  we  progress 
down  the  organization  the  product  will  become  easier  to 
grasp.  The  span  of  management  control  and  resource  respon- 
sioilities  will  decrease.  Therefore,  one  must  remember  to 
ensure  the  product  and  the  level  of  the  organization  match. 
All  too  often  people  are  evaluated  on  their  ability  to 
produce  a  product  which  they  were  :iot  assigned  to  produce 
nor  had  any  role  in  producing. 
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Unfortunately  the  reader  will  find  in  this  section 
several  terms  that  have  multiple  mailings.  This  is  inesca- 
pable because  there  has  been  no  aroepted  set  of  standard 
definitions  within  the  software  development  industry. 

A.   PROJECTS  AS  PRODUCTS 

The  "contracted  projeot",  genericaliy,  is  a  software 
development  tasking  for  which  an  organization  contracts 
another  to  produce.  It  nay  consist  of  a  number  of  sub- 
projects  or  programs.  An  example  is  the  development  of  an 
operating  system  which  iaoludes  a  jsb  scheduler,  process 
scheduler  and   file  manager,   Figure   3.1  shows   the  various 
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contracted  project  assigned  project 

milestones  (1)  management/support  (1) 
design  specifications    functional  specifications 

lines  of  code  modules 

function  (user)  function  (computer) 

test  code  documentation 

(1)  not  deliverable  products 


Figure  3.1    Software  Development  Products. 

component  products  of  a  project.  The  project,  an  operating 
system,  must  integrate  each  of  thsse  various  parts  to  be 
complete.  Therefore,  tae  guestion  of  productivity  here  is 
whether  or  not  the  project  can  be  ieLivered  on  budget  and  on 

schedule. 
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If  the  contracted  project  is  large,  as  in  the  operating 
system  example,  it  will  be  broken  down  into  several  smaller 
projects,  which  I  call  "assigned  projects"  since  there  is 
little  choice  as  to  who  will  manage  them  once  the  contracted 
project  is  accepted.  The  assigned  projects  will  be  given  to 
several  project  managers  who  will  report  to  the  central 
contracted  project  manager.  The  role  of  each  of  these 
project  managers  is  to  deliver  a  fully  complete  integrated 
operating  product. 

The  guestion  at  this  point  is,  "Are  these  good  items  by 
which  to  measure  productivity?".  !fes,  they  are,  for  several 
reasons.  First,  for  this  level  of  management  they  are  the 
only  products  that  are  produced.  Second,  the  reason  for  the 
manager  to  hold  the  particular  job  of  project  manager  is  for 
his/her  to  deliver  a  projeot  on  time,  within,  budget  and  to 
the  satisfaction  of  the  customer  so  that  the  organization 
may  make  its  profit.  What  about  the  difference  in  languages 
used  or  the  sizes  of  various  projects?  These  questions  need 
to  take  their  rightful  plaoe  in  the  lata  base  of  information 
of  the  ccrpcration.  Eaca  productivity  measure  has  a  set  of 
parameters  within  which  it  can  only  be  used.  There  is  a 
definite  need  to  know  how  capable  a  project  manager  is  at: 
1)  developing  any  project;  2)  using  i  specific  language;  3) 
developing  various  sized  projects;  !*)  developing  machine 
dependent  projects;  5>  developing  first-of -its-kind 
projects;  or  6)  modifying  a  generic  project. 

Each  of  these  parameters  gives  added  insight  to  a 
project  manager's  productivity  rating.  The  first  lets  one 
know  hew  productive  he/she  is  relative  to  all  the  other 
project  managers  regardless  of  projsct  specifics.  Each  of 
the  other  measures  provide  additional  information  on  the 
relative  productivity  of  a  project  manager  within  the  diffe- 
rent parameters.  dse  of  all  of  th=ss  productivity  ratings 
by  the  next  higher  level   of  management   may  improve   both 
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levels  of  managements  producti/ity  provided  project 
managers  are  well  matched  to  projects  where  their 
productivity  is  highest. 

B.   HILESTOHES  A HD  MANA3EME  NT/SOPPDEtr 

At  this  point  it  may  be  advantageous  to  discuss  a 
management  tool  that  many  may  consider  to  be  or  confuse 
with,  a  product.  A  "milestone"  is  a  point  in  the  life  of  a 
development  project  when  a  deliverable  product,  as  listed  in 
Figure  3.1  ,  should  be  oouoleted.  Many  would  think  that  the 
ability  to  meet  project  milestones  shows  great  productivity. 
This  is  not  true.  For  if  it  were  true,  first  the  milestone 
must,  in  fact,  mean  the  production  of  a  deliverable  item. 
Second,  the  deliverable  item  must  be  something  of  value  to 
the  project.  If  the  deliverable  is,  in  fact,  of  significant 
value  to  the  project  then  the  production  of  that  item  is  the 
basis  fcr  one's  measure  and  not  the  meeting  of  a  milestone. 
The  meeting  of  the  milestone  shows  only  that  the  project  is 
proceeding  as  planned.  Phe  milestoie  has  no  other  inherent 
value.  That  is,  one  does  not  deliver  a  milestone  as  one 
would  a  program.  The  milestone  is  only  another  management 
tool  just  as  is  a  productivity  measure. 

Like  milestones,  Management/Support  is  not  a  product  but 
a  management  tool.  However,  the  type,  quality  and  quantity 
of  the  support  must  be  considered  very  carefully. 
Management/support  exacts  a  price  in  that  it  is  an  overhead 
expense.  Its  value  is  not  as  a  product  but  as  a  tool. 
nearly  all  presentations  discussing  productivity  refer  to 
the  management/support  tools.  This  is  where  the  vendors  and 
consultants  make  a  great  deal  of  noney.  They  speak  of 
productivity  improvement  and  the  aids  that  provide  it. 
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There  are  two  parts  to  this  concept,  management  tools 
and  support  tools.  The  management  side  deals  with  systems 
that  help  predict  costs  and  time  schedules  and  those  that 
track  the  progress  against  the  predictions  and  plans.  At 
FMSO,  this  function  is  under  the  auspices  of  the  Management 
Department,  Code  92  [Ref.  10]  where  PAC-II  is  used  to  track 
and  DOD  MICRO  and  SLIM  are  used  to  estimate  software  costs 
and  time  schedules.  The  value  of  this  support  can  be  very 
subjective.  Often  the  value  of  tha  management  aid  is  that 
it  gives  the  manager  much  more  confidence  in  his/her  deci- 
sions. The  effect  of  the  use  of  these  kinds  of  tools  may 
also  be  seen  on  the  ledger.  If  the  systems  help  management, 
all  else  being  equal,  one  would  expect  to  see  fewer  cost 
overruns  and  better  personnel  management. 

The  support  side  has  a  miriad  of  tools  than  predict 
sure-fire  ways  to  improve  productivity  dramatically.  These 
tools  include  various  design  procedures  (i.e.  structured, 
top-down,  modular  design),  on-line  programming  and  provision 
for  each  programmer  to  have  his/her  own  CRT  terminal  to 
mention  a  few.  T.C.  Jones  [Ref.  11]  discusses  more  of  these 
tools  and  their  respective  limitations. 

The  fact  that  management/support  is  not  a  product  does 
not  minimize  its  importance.  On  the  contrary,  it  is  vital 
to  effective  software  development.  But  the  manager  must 
realize  that  the  addition  of  each  piece  of  management/ 
support  costs  money  for  which  accounting  must  be  made. 
Although,  there  are  many  management/support  systems  which 
may  improve  productivity,  the  indiscriminate  implementation 
of  their  use  will  not  necessarily  lead  to  productivity 
improvements.  The  use  aid  expansion  of  management/support 
is  an  area  worthy  of  further  study. 
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C.   DESIGN  AND  FUNCTIONAL  SPECIFICATIONS 

Design  specifications  are  usually  thought  of  as  a 
product  cf  the  contracting  organization.  They  are  used  as 
tha  basis  from  which  to  make  a  contractual  bid  and  to  writs 
tha  functional  specifications.  Howe/er,  the  design  specifi- 
cations, as  delivered,  oftan  must  be  rewritten  by  tha 
contractor  in  close  conjunction  with  the  contracting  organi- 
zation so  that  they  are  explicit  anough  to  properly  writa 
tha  functional  specifications. 

Both  Keider  [Bef.  12]  and  Howdea  [ Hef .  13]  discuss  tha 
need  for  well  thought  out  and  well  written  design  specifica- 
tions. Keider ■ s  article,  "Why  Projects  Fail",  shows  how 
poorly  planned  projects  waste  money  and  resources.  Howden's 
article,  "Life-Cycle  Software  Validation",  discusses  tha 
nead  for  project  design  spa cificatiois  to  meet  five  proper- 
tias.  First,  the  spacif ications  must  ba  consistent 
internally  as  well  as  in  any  relatad  documents  or  other 
portions  of  the  project.  Second,  the  specifications  must  ba 
complete.  Thay  must  ba  axamined  for  missing  or  incomplete 
inf or  ma-ion  reguirements  and  to  ensure  data  properties  ara 
included.  Third,  tha  s?  ecif  icatiDP.s  should  only  include 
neoessary  items  without  redundancy  (not  to  be  confused  with 
hardware  redundancy  to  eisure  reliability).  Fourth,  the 
system  must  be  feasible  with  existing  technology  and  hard- 
ware. And  fifth,  the  specifications  must  use  correct  math 
formulas  and  decision  tables. 

The  reader  should  racognize  that  the  validation  of 
design  specifications  ar.i  functional  specifications  is  a 
ncntriviai  task.  The  systems  analysts  who  validate  the 
design  specifications  and  who  writa  and  validate  the  func- 
tional specifications  muse  ba  held  accountable  for  their 
resource  use  in  the  production  of  these  products.  The 
specifications  need  to  be   examined  oarefully,   as  discussed 
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above,  especially  when  one  considers  that  approximately 
forty  percent  of  a  projects  resources  are  used  in  the  design 
phase  [Ref.  37].  Poor  quality  here  is  very  difficult  and 
costly  to  try  to  overcome  later  in  the  software  development 
cycle. 

D.   LINES  OF  CODE  AS  A  PRODUCT 

The  line-of-code  (LOC)  is,  by  far,  the  predominant 
measure  used  throughout  industry  to  iiscuss  program  size  and 
productivity  ratings  foe  all  levels  af  software  development. 
Interestingly,  though  the  entire  industry  uses  LOC  as  a 
measure  cf  product  definition,  few  agree  as  to  what  a  LOC 
is.  One  of  the  first  questions  as<ed  is,  "Do  you  mean  a 
line  of  object  cede  or  source  code?".  The  industry  has  had 
scie  success  in  distinguishing  between  them  but  not  in 
choosing  one  or  the  other  as  a  universal  measure.  Source 
coie  is  that  written  by  the  programner  while  object  code  is 
the  compiled  code  stored  in  nemory.  Source  code  is  more 
often  used  to  describe  programmer  productivity  than  object 
coie  which  is  usually  used  to  define  the  quantity  of 
computer  memory  reguirei  to  stara  the  program  code 
[Ref.  14]. 

Assuming  one  has  settled  on  source  code  as  a  part  of  the 
measure,  what  determines  a  line  of  code?  SDme  have  said 
each  line  or  statement  written  by  the  programmer  regardless 
of  length.  Others  try  to  force  the  line  to  have  eighty 
characters.  Still  others  try  to  define  it  by  statement 
punctua-ion  characters  by  language  (i.e.  periods  in  COBOL  or 
semicolons  in  PASCAL) . 

If  this  weren't  bad  enough,  the  next  question  is, 
"Which  of  the  lines  are  'countable1?".  That  is,  some  want 
to  differentiate  between  executable  statements,  data  decla- 
rations, comments,  ncndeliverable  debugging  or  testing  aids. 
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etc.  Use  of  LOC  each  of  these  areas  must  be  explicitly 
defined  because  studies  have  shown  line  count  variations  of 
more  than  two-to-one  on  the  same  program  [ Ref •  15]. 

After  the  LOC  is  well  defined  and  published,  one  must 
watch  carefully  because,  just  as  the  measure  helps  manage- 
ment to  rate  personnel,  so  does  it  hslp  personnel  to  promote 
themselves,  often  by  manipulating  the  rules  in  their  favor. 
Here  are  several  examples.  One  company  settled  on  every 
line  written  regardless  of  length.  After  some  examination 
of  several  programs,  lines  were  found  not  to  be  complete 
statements  nor  eighty  characters  in  length,  thus  padding  the 
trie  productvity  levels.  Another  may  decide  to  use  eighty 
characters  as  the  defined  line.  In  this  case  it  would  not 
be  unusual  to  find  variables  with  extremely  long  names  or 
use  of  the  "blank"  character  to  fill  up  lines  and  thus  pad 
the  productivity  rating.  Paradoxically,  the  programmers  may 
be  forced  to  have  large  numbers  of  blank  characters  if 
management  reguires  the  use  of  structured  programming  tech- 
niques. Another  problem  is  that  programmers  may  fight  the 
use  of  higher  level  languages  so  they  may  program  in  a 
language  in  which  they  are  comfortable  and  which  requires 
more  lines  to  accomplish  the  same  task.  Jones  [Ref.  15# 
p.»1-43]  discusses  the  LOC  measure  more  extensively  than 
presented  here. 

Since  the  measure  is  so  difficult  to  define  and  may  lead 
to  unacceptable  programaiag  practices,  as  stated  above,  or 
caise  paradoxical  conclusions,  as  iiscusssd  in  the  following 
chapter,  this  researcher  feels  LOC  is  a  poor  product 
measure.  However,  this  ioes  not  mean  to  say  that  there  is 
no  use  for  LOC  as  a  product  measure.  In  fact  it  is  the  only 
measure  available  when  one  is  performing  maintenance  on 
programs  which  entails  changing  individual  lines  in  a 
program.   Therfore,  we  must  have  a  definition  for  a  LOC. 
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There  are  many  different  languages  in  which  one  can 
program.  Since  each  has  its  own  rules  of  construction  the 
definition  of  a  LOC  will  necessarily  be  different  for  each 
language.  This  researcher  prefers  to  view  a  line  of  code  in 
tha  context  of  a  complete  sentence  or  phrase  of  spoken 
language.  Each  programming  language  has  a  defined  equiva- 
lent of  a  complete  statement  or  phrase.  Just  as  Hemingway 
and  Faulkner  had  different  styles  of  conveying  information, 
so  will  programmers.  This  is  not  a  detriment  to  programming 
any  more  than  it  is  to  writing.  Programmers  will  settle 
into  standard  line  lengths  with  which  each  is  comfortable. 
As  long  as  management  is  satisfied  that  the  style  fits  well 
into  the  structure  of  the  language  then  there  should  be  no 
problem.  This  does  require  management  to  supervise  and  to 
train  these  that  are  not  consistent  in  their  own  programming 
or  are  far  from  the  "avenge"  line  length  of  the  rest  of  the 
programmers. 

The  countable  lines  should  be  those  that  are  vital  to 
the  program  quality  and  specific  language.  The  lines  that 
are  niceties  but  which  aid  in  the  readability  of  programs 
have  geed  reason  to  be  in  programs.  They  should  be  counted 
but  not  with  full  credit.  The  comnent  line  is  an  example. 
It  is  necessary  for  readability  bit  a  one  hundred  line 
program  does  not  need  in  additional  hundred  lines  of 
comments.  Contrarty  to  others,  tils  researcher  believes 
soae  credit  should  be  given  for  comment  lines.  However,  to 
keep  verbosity  out  of  programs  due  to  comment  lines  and  to 
be  consistent  with  the  creiit  given  for  reused  code 
[Hef.  16],  they  should  only  count  as  twenty  percent  and  then 
should  be  a  full  eighty  characters  long.  Lines  that  are 
executable  or  data  declarations  ani  the  like  should  be 
counted  fully  as  one  line. 
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If  LOC  is  used  as  a  measure  for  program  length,  it 
should  be  measured  as  a  block  of  L3C,  haing  at  least  one 
hundred  lines  and  not  mire  than  one  thousand  lines  per 
block.  There  are  two  reasons  to  do  this.  First,  each  block 
of  LOC  can  have  a  time  v alue  association.  This  allows 
developers  to  speak  in  tarns  of  time  per  block  of  code. 
This  is  valuable  when  trying  to  estimate  the  time  required 
to  develop  a  program  estimated  to  be  some  number  of  blocks 
of  code  long.  Second,  cole  must  have  an  intrinsic  quality. 
It  makes  little  ssnse  to  liscuss  one  tested,  debugged  and 
documented  LOC.  But  it  ioes  make  ssnse  to  discuss  a  block 
of  code  with  the  same  qualitias.  This  tends  to  force  the 
cole  to  have  some  minimum  level  of  quality.  The  quality 
requirement  takes  into  consideration  the  time  spent  by  the 
programmer  in  writing  non-ielivered  test  code  and  debugging 
aids  and  in  correcting  logic  errors.  When  LOC  are  reused 
tha  count  value  should  be  a  percentage  of  one  original  LOC. 
Basiii  and  Freberger  [Bef.  16]  use  twenty  percent  in  their 
research.  This  researcher  recommenis  starting  with  twenty 
percent  and  then  adjusting  it  according  to  the  percentage  of 
time  required  to  locate  reusable  cole  instead  of  developing 
original  code. 

E.   MODULE  AS  PRODUCTS 

A  module  is  a  single,  intellectually  managable  portion 
of  a  program  which  is  separately  conpilable  but  which  must 
have  connections  to  other  modules.  Its  size  is  variable  but 
it  contains  only  one  complete  responsibility  assignment  of  a 
program.  It  has  only  one  antry  point  ind  one  exit  point  and 
conforms  to  the  permitted  logic  structures  of  structured 
programming.  The  responsibility  assignments  are  determined 
during  the  design  phasa  before  any  work  on  individual 
modules  is  begun.   One  of  the  key  araas  of  modular  design  is 
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tha  selection  of  module  contents  based  on  the  probability  of 
change  during  the  maintenance  phase.  In  other  words,  assign 
those  portions  of  programs/projects  that  are  likely  to 
change  due  to  hardware  or  technology  to  their  own  respective 
modules.  The  advantage  gained  by  this  bit  of  overhead  is 
found  in  the  cost  avoidance  which  foLlows  during  the  mainte- 
nance stage,  where  up  to  seventy  percent  of  a  projects 
costs  lie. 

There  is  a  paradox  concerning  maintenance  and  well 
written  code.  If  one  measures  productivity  during  the 
maintenance  phase  by  cost  per  defect,  a  popular  method, 
he/she  will  find  that  very  poorly  written  code  has  a  lower 
cost  per  defect  than  well  written  code.  This  occurs  because 
poorly  written  code  has  many  errors  which  programmers  must 
spend  much  time  correcting.  They,  therefore,  become  very 
familiar  with  the  program.  The  initial  costs  of  relearning 
the  program  logic  are  spread  over  many  errors  in  poorly 
written  cede,  and  over  very  few  errors  in  well  written  code. 
However,  the  total  cost  Df  maintaining  well  written  code  is 
usually  much  lower.  If  one  were  to  take  the  same  well 
written  modular  code  and  compare  it  to  the  same  well  written 
non-modular  code  one  should  find:  1)  fewer  logic  errors 
because  of  the   extensive  analysis  during  the   design  phase; 

2)  it's  easier  to  locate  errors  since  they  can  often  be 
traced  to  one  module  or  at  least  to  a  branch  of  the  program; 

3)  it's  easier  to  relearn  the  logic  because  of  the  need  to 
only  learn  one  or  a  few  modules  instead  of  the  entire 
program.  If  any  or  all  of  these  points  are  realized,  FMSO 
could  save  a  great  deal  in  resources  and  improve  customer 
satisfaction.  Since  FSSD  presently  must  maintain  over  9^00 
programs  and  respond  to  :>ver  3203  program  trouble  reports 
(PTP.)  annually,  any  reduction  in  the  cost,  in  time  or  money, 

on  a  per  item  basis  could  lead  to  significant  savings  and 
higher  productivity  ratings  fsr  program  maintenance 
personnel. 
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The  use  of  modular  programming  allows  two  other  areas  to 
be  explored.  The  first  is  Parnas*  [Ref.  17]  idea  of  program 
families.  The  idea  is  to  look  at  similarities  in  programs 
before  looking  at  thsir  differences  and  write  generic 
programs  based  on  the  similarities.  Then  one  adds  the 
modules  that  will  make  the  programs  individualistic.  In 
this  way  programmers  can  reuse  existing  code  which  is  well 
tested  and  with  which  programmers  are  thoroughly  familiar. 
This  helps  to  reduce  initial  project  development  time  and 
costs  and  to  reduce  maintenance  costs. 

The  second  area  is  that  which  Zoll  [Ref.  13  ,  p.  51] 
refers  to  as  "metaprogramming".  This  is  the  use  of  data 
base  libraries  of  modular  cods  to  build  complete  programs. 
The  code  is  generic  and  the  metaprogrammer  merely  researchs 
*he  data  base  and  selects  those  modules  which  will  meet  the 
program  logic.  In  this  way  progranmers  write  much  less 
original  code.  Lanergan  and  Poynton  [Ref.  19]  report  that 
at  Raytheon  Company  some  ns  w  applications  software  have  been 
developed  forty  times  faster  than  by  using  traditional 
development  methods.  Reised  modules  have  been  averaging 
between  forty  and  sixty  percent  of  the  total  LOC  on  major 
projects.  The  probability  of  inducing  logic  errors  is 
reduced  significantly  and  the  probability  of  textual  errors 
is  also  reduced  due  to  tha  reduced  amount  of  original  code 
required.  Kendall  and  Lamb  [Ref.  2D],  in  their  research  at 
IBS,  have  reported  data  which  shows  that  metaprogramming 
from  a  data  base  of  modules  should  be  seriously  considered. 
Their  study  showed  that  =ighty  percent  of  the  applications 
programming  effort  goes  into  production  of  programs  whose 
us=d  life  is  less  than  eighteen  months.  Therefore,  any 
reduction  in  the  effort  to  develop  these  programs  and  any 
reduction  in  the  maintenance  effort  of  these  programs  will 
provide  a  factor  of  four  increase  in  the  savings  to  be 
applied  to  the  maintenance  of  the  twenty  percent  portion  of 
the  programs  with  a  siginf icantly  longer  life  cycle. 
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The  added  attraction  of  modular  code  is  the  idea  of 
completeness  of  the  task.  For  a  quality  module  to  be  deliv- 
ered for  integration  it  must  be:  1|  documented;  2)  coded  in 
its  entirety;  3)  tested;  and  4)  debugged.  These  are  much 
more  difficult  tc  attain  with  LOC  as  the  product.  In  parti- 
cular, it  is  very  difficult  to  test  a  block  of  LOC  since  it 
relies  heavily  on  the  remainder  of  the  code.  Therefore,  it 
can  only  be  examined  by  inspection  while  modules  can  be 
inspected  and  machine  dabjgged  to  a  near  zero  defect  condi- 
tion prior  to  integration.  Although  the  documentation  is 
not.  vital  for  module  delivery,  it  can  be  and  should  be  an 
organizational  requirement. 

The  idea  of  designing  projects,  especially  large  ones, 
by  dividing  them  into  subprograms  or  modules  is  a  very  old 
concept  in  programming.  During  the  1970's  it  became  a  topic 
of  high  interest  as  a  way  to  improve  program  reliability  and 
maintainablility .  Boss  at  al  [Ref.  21],  Liskov  [Ref.  22], 
Crossman  [  Ref .  23],  and  Parnas  *  Ref .  24]  [Ref.  17]  wrota 
formidable  papers  extolling  the  virtues  of  modular  program- 
ming. Yet  there  are  many  software  development  organizations 
that  do  not  understand  taa  term,  ise  or  value  of  modular 
programming.  The  Departmant  of  Dafsnse  (DOD)  appears  to  be 
ona  organization  that  does  not  fully  understand  the  value  of 
modularization  and  reusiig  code.  lunson  [Ref.  25]  points 
this  out  in  his  short  pap  =  r  on  reducing  software  costs  by 
reusing  code.  Elshoff  [Ref.  26]  observed  this  problem  at 
the  General  Motors  Research  Lab  wi  =  re  modularization  not 
only  appeared  foreign  to  analysts  and  programaars  but  was 
vi=wed  as  detrimental  to  the  software  life  cycle.  The 
nnf amiliarity  with  modularity  is  also  present  at  the  US 
Navy's  Fleet  Numerical  and  Dceanographic  Center  in  some 
analysts  and  programmers.  While  this  does  not  appear  to  be 
a  problem  at  FMSO  at  the  presant,  internal  training  may  be 
required  because  of  turnovar  of  software  development 
personnel. 
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This  section  concerns  quality  modules.  These  are 
modules  that  are  coded  in  their  entirety,  tested,  debugged, 
and  documented.  Each  organization  will  have  to  set  up  the 
requirements  for  a  countable  modula.  This  researcher  recom- 
mends these  attributes.  They  ansure  attainment  of  the 
organization's  minimum  quality  standards  and  take  into 
consideration  the  programmer's  time  in  debugging  and  testing 
tha  module.  When  reused  aodulas  are  a  part  of  the  delivered 
product  they  should  be  counted  as  a  percentage  of  one 
module.  Basili  [ Ref .  15]  used  twenty  percent  in  his 
research.  This  is  a  goDd  starting  point.  But  if  the 
organization  finds  that  this  is  not  an  accurate  percentage 
of  the  time  required  to  develop  original  modules  then  the 
percentage  should  be  adjusted  accordingly. 

F.   USER  FDNCTIOHS  AS  PRODJCTS 

The  previous  section  dealt  with  functions  based  on 
program  structure.  This  section  deals  with  functions  based 
on  user  requirements.  While  modules  may  vary  in  length  by 
approximately  one  hundred  lines  of  code,  user  functions  can 
vary  up  to  several  prograns .  An  exaaple  of  this  is  a  single 
entry  accounting  system.  A  company  may  want  a  system  which 
performs  several  functiois  such  as:  ledger  maintenance, 
invoicing,  file  maintenance,  weekly  reporting,  ate.  Each  of 
these  operations  or  functions,  is  a  deliverable  product  to 
tha  customer  as  a  part  of  the  single  entry  accounting 
package.  The  quality  of  the  entire  package  is  determined  by 
tha  customer  satisfaction  with  aach  individual  function. 
Albrecht,  [Ref.  27]  of  IBM  Corporation,  uses  this  measure  as 
the  primary  means  of  determining  productivity  ratings  in  the 
Applications  Development  5roup.  He  points  out  that  one  must 
be  careful  when  using  this  measure  :>  r  any  other  measure  by 
keeoing  the  major  project  objectives  in  perspective:  on 
tine,  within  budget,  and  a  satisfied  customer. 
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The  specific  product  aeasure  is  what  Albrecht  calls  a 
function  value.  The  approach  to  determine  the  function 
value  is  to  count  the  number  of  external  user  inputs,  inqui- 
ries, outputs  and  master  files  that  the  project  must  develop 
as  a  part  of  the  user  requirements.  An  external  user  input 
is  a  communication  from  the  user  to  the  computer  such  as 
data  forms,  terminal  screens,  keyboard  transactions,  optical 
scanner  forms  and  the  like.  These  lo  not  include  inputs 
from  tapes  and  data  sets,  which  are  considered  as  internal 
and  part  of  the  file  count.  Each  of  these  user  functions  is 
weighted  by  a  value  designed  to  reflect  that  function's 
value  to  the  customer.  Appendix  I  shows  the  details  of 
determining  the  function  value  and  Appendix  II  shows  the 
details  of  determining  the  sizing  and  complexity  of  an 
entire  project  using  function  value  oomponents.  Appendix  II 
uses  the  same  external  user  inputs  and  some  internal  inputs 
as  components  to  compute  the  function  points  but  also 
provides  for  the  the  computation  of  a  development  time  esti- 
mation. It  is  important  to  note  that  Chrysler  [ Ref •  2] 
showed  in  an  unrelated  and  independent  study  that  these 
components  were  most  significant  in  predicting  development 
tiae. 

Albrecht' s  function  value  concept  has  several  advantages 
over  those  measures  previously  mentioned.  First,  it  is  the 
only  measure  that  deals  specifically  and  directly  with  user 
satisfaction.  The  other  neasurss  virtually  ignore  the  user 
between  the  functional  specification  phase  and  the  implemen- 
tation phase.  This  method  constantly  works  with  the  user. 
Secondly,  since  its  focus  is  on  user  requirenents  and  not 
on  counting  lines  or  blocks  of  code  or  modules,  it  tends  to 
liait  programmer  gaming  to  improve  his/her  productivity 
rating  artificially.  Third,  the  aeacure  breaks  the  project 
into  user  defined  portions  of  importance.  This  focuses  the 
effort  towards   teamwork  since   it  requires   the  development 
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group  to  work  as  a  team  toward  the  production  of  functions 
to  which  the  user  has  placed  a  wall  defined  importance. 
Lastly,  the  method  provides  more  opportunity  for  a  smoother 
evolution  of  change  than  the  others.  It  focuses  attention 
on  the  cost  of  each  f anot ion  and  the  effects  on  cost  of 
mid-development  changes.  The  constait  attention  to  cost  and 
user  involvement  provides  a  better  nechanism  to  control  the 
change  process  during  development.  It  enables  the  planner 
to  design  for  changes  that  may  occur  during  the  life  cycle 
that  may  not  be  cost  affective  to  include  during  the 
development  phase. 

The  function  value  concept  has  three  disadvantages. 
First,  there  may  some  question  as  to  whether  to  call  a 
component  an  inquiry  or  an  input.  These  ace  not  always 
distinct  items.  If  the  weighting  factors  are  different  for 
each  this  may  significantly  alter  the  final  function  value. 
Second,  users  play  a  larg*  part  in  determining  the  weighting 
factors,  as  it  should  be.  Users  can  be  fickle,  therefore, 
it  is  often  extremely  difficult  to  get  them  to  admit  "truth- 
fully" what  they  desire  most.  It  is  not  so  much  that  they 
are  hiding  information  but  that  they  don't  really  know  what 
they  want.  Therefore,  it  requires  talented  interviewers  and 
designers  to  determine  th=  true  desires  of  the  users.  The 
third  disadvantage  is  that  this  usasure  is  so  good  that 
managers  may  tend  to  rely  on  it  too  heavily.  This  is  not 
the  ultimate  or  universal  measure  but  it  is  a  good  one.  The 
otier  measures  can  give  insights  02  products  and  produc- 
tivity that  this  measure  cin  not.  The  function  value  is  an 
aggregate  measure  and  must  be  used  as  such.  As  Stevens 
[Ref.  28]  of  Performance  Management  Associates  Inc.  of 
Scottsdale  (Az. )  points  Dut,  there  is  no  universal  measure 
yet.  We  must  use  all  the  imperfect  nsasures  available  in  an 
effort  tc  describe  the  programming  activity. 
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G.   TESTING,  INTEGRATION,  fcND  I HPLEMENT ATION 

One  of  the  concerns  of  managers,  whsn  discussing 
programmer  productivity,  is  ho*  to  iicorporate  non-delivered 
code  in  the  calculation  of  productivity.  The  non-delivered 
code  consists  of  test  cods,  debugging  aids  and  incorrect 
code.  The  incorrect  cods  is  a  function  of  ths  programmer's 
skill  and  is  a  penalty  to  nis/her  productivity  rating.  Ths 
test  code  and  debugging  aids  are  not  mistakes.  They  are 
ussd  by  skillsd  programmscs  to  ensure  coding  guality  and 
correctness.  There  has  been  some  concern  that  ths 
programmer  should  have  this  code  included  with  the  delivered 
cods  for  productivity  calculations.  This  rsssarcher  does 
not  concur  that  the  test  code  and  dsbugging  aids  should  be 
included.  Ths  programmsc 's  job  is  to  deliver  code  that 
meats  the  specifications.  Ths  only  way  to  ensure  the  cods 
actually  meets  those  specifications  is  to  perform  some  type 
of  test.  Test  code  and  debugging  aids  are  tools  of  the 
programmers  just  as  milestones  and  management/support  are 
tools  fcr  others  in  ths  software  isvslcpment  arena.  Thsy 
ars  a  necessary  overhead  4 hich  programmers  muse  employ  if 
thsy  are  to  deliver  the  quality  products  discussed 
pra  viously. 

The  integration,  tasting  and  implementation  phase  of 
software  development  utilizes  approximately  forty  percent  of 
ths  project's  resources  [3sf.  37  ,p.18].  Intuitively,  ons 
would  think  that  an  area  which  uses  so  much  of  the  resources 
would  be  a  prime  placs  to  do  some  productivity  research. 
This,  unfortunately,  is  not  the  case.  One  of  the  prims 
reasons  has  been  the  inability  of  the  industry  to  determine 
ths  role  these  activitiss  play.  Specifically,  there  is  a 
qusstion  as  to  whether  testing  is  a  part  of  devslopment  or  a 
part  of  quality  assurance.  If  it  is  part  of  guality  assu- 
rance then  it  is  an  cverhsad  and  not  a  productivity  concern. 
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If  it  is  a  part  of  development  then  the  product  is  tested 
and  acceptable  code.  But  what  deternines  how  productive  the 
testing  is?  The  time  expanded  in  tasting  does  not  help  to 
determine  the  productivity  of  testing  because  the  time  used 
in  testing  is  a  function  of  the  -cast  plan  and  the  number  of 
defects  found.  Defects  found  does  help  to  determine  produc- 
tivity. It  shows  either  poor  design,  poor  programming,  poor 
quality  assurance  practices  or  any  combination  thereof. 

Integration  is  left  with  the  same  type  of  problems. 
This  activity  takes  project  portions,  modules,  LOC,  or 
programs,  and  brings  then  together  to  form  a  cohesive  and 
integrated  product.  But  if  there  are  major  difficulties 
encountered  are  they  the  the  fault  of  the  integrators? 
Probably  not.  The  fault  probably  li*s  with  the  designers  or 
the  programmers. 

The  manager  must  ba  aware  of  ths  problems  that  develop 
during  this  phase  and  keep  records  of  them.  Though  there 
were  no  conclusive  reports  found  o.i  how  to  deal  with  the 
information,  the  consensus  from  tha  literature  is  that  it 
must  kept  in  a  data  base  for  later  study  and  consideration. 
Tha  science  of  software  davelopment  has  net  progressed  far 
enough  to  completely  handla  tha  test,  integration  and  imple- 
mentation problem.  Most  researchers  are  of  tha  belief  that 
if  we  get  control  of  the  development  process  in  a  scientific 
way  these  problem  areas  may  disappaar. 

H.   DOCOHENTATION 

The  primary  belief  in  the  indusrty  and  particularly  in 
DOD  is  that  software  development  projacts  have  two  separate 
products:  program  code  and  program  documentation.  This  is 
an  extremely  s hcrt-sightad  but  understandable  belief.  As 
long  as  software  development  is  viewed  as  having  two 
products,   this   belief  presents  tha  opportunity   to  discard 
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one.  Since  the  program  is  what  is  wanted,  all  too  often  the 
documentation  is  reducel  in  an  attempt  to  reduce  development 
costs.  The  view  that  there  are  two  products  and  the  prac- 
tise of  reducing  the  documentation  thrive  on  ths  belief  that 
software  development  and  software  maintenance  are  not 
related.  This  is  not  true.  The  documentation  is  required 
to  learn  the  program  logic  and  coding  structure.  A  software 
project  that  was  poorly  designed  and  poorly  or  not 

documented  is  extremely  difficult  and  much  more  costly  to 
maintain  than  one  that  was  nail  designed  and  well  docu- 
mented. Nearly  every  other  industry  (i.e.  automobile, 
electronics,  machine  tools,  etc.)  that  produces  a  complex 
product  provides  documentation  on  tie  logic  and  design  of 
that  product  so  that  maintenance  personnel  can  provide 
quality  and  cost  effective  maintenance.  There  is  no  reason 
to  believe  that  the  software  development  industry  should  be 
any  different. 

This  researcher  beiie/es  that  documentation  is  not  a 
separate  product  but  an  integral  pact  of  all  well  developed 
software  projects.  This  chapter  consistently  discussed 
fully  coded,  well  documented  quality  software.  It  should  be 
intuitively  obvious  that  a  program  that  does  not  operate 
properly  is  of  little  or  ao  value.  And  that  one  that  oper- 
ates properly  but  is  difficult  to  mderstand  and  maintain 
because  cf  poor  documentation  is  of  nuch  less  value  than  one 
with  superior  documentation.  Thus,  the  documentation  has  no 
specific  measure  of  length  only  one  of  quality.  It  is  a 
problem  for  the  developers  and  quality  assurance  experts  to 
ensure  that  the  documentac ion  is  provided  and  adequate  in 
describing  the  program  logic  and  coding  structure  of  the 
pro  ject. 
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17.  THE  MEASURES 

During  the  research  for  this  piper  it  was  noted  that 
thare  is  a  great  deal  of  misunderstanding  both  in  the  liter- 
ature and  in  the  industry  about  programming  and  software 
development  productivity.  The  misuiderst anding  lies  in  the 
area  that,  when  questioned  about  the  product  that  is 
produced,  one  will  receive  quizzical  looks  or  long  spells  of 
silence.  People  immediately  want  to  jump  to  discussions  on 
complexity,  language,  tools  or  the  development  environment. 
These  have  little  to  do  with  calculating  productivity. 
Thair  roles  are  as  parameters  within  which  one  must  analyze 
the  specific  productivity  rating.  This  is  not  to  belittle 
tha  importance  of  these  areas.  It  is  simply  a  matter  of 
organizing  one's  thoughts.  One  can  not  intelligently  speak 
of  improving  productivity  intil  one  first  has  a  quantitative 
measure  and  secondly  a  description  of  the  environment.  Too 
often  people  in  the  industry  look  at  the  environment  not 
only  first  but  exclusively.  Without  a  product  definition 
and  the  measure,  the  environment  cannot  be  understood. 

Productivity  has  two  components:  outputs  and  inputs. 
Tha  outputs,  loosely  defined,  are  the  products  previously 
discussed:  projects,  programs,  functions  points,  modules, 
and  LOC.  They  are  dependant  on  tha  corporate  hierarchical 
level  and  the  philosophy  jsed  for  software  development.  The 
inputs  vary  considerably  depending  ipon  which  productivity 
measure  one  is  interests!.  The  most  common  input  used  is 
the  person-month,  160-175  hours.  This  can  ba  broken  down 
into  its  various  parts  by  programmers,  management/support, 
systems  analysts,  and  program  analysts.  3ut  there  are  other 
inputs  that  may  be  worth  considering  such  as  CPU  time  or 
terminal  connect  time.  Though,  thase  are  rarely  if  ever, 
considered. 
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A.   LOC  PER  PROGRAMMER-MONTH 

The  most  common  measure  used  for  assessing  productivity 
throughout  the  industry  is  LOC  per  programmer-month.  Though 
a  /ery  popular  measure,  it  is  not  very  good.  Since  it  is 
based  on  LOC  it  is  subject  to  the  Line  counting  variations 
mentioned  in  the  previous  chapter.  This  variation  can  be 
United,  to  a  certain  aitent,  by  setting  organizational 
standards  as  rsccmmendei  aarliar.  This  would  parmit  consis- 
tency in  the  organizatioi  bat  not  across  the  industry. 
Recall,  one  of  the  reasons  for  measuring  is  to  maka  compari- 
sons across  organizational  lines.  As  long  as  there  ara 
variations  in  the  definitions  of  conponents  no  intelligent 
comparisons  can  be  made. 

LOC  per  programmer- mo a th  is  insffactive  for  noncoding 
tasks*  The  tendency  when  computing  this  measure  is  to  usa 
programmer-month  as  tha  total  development  time  which 
inoiudes  these  noncoding  tasks  of  iesign,  documentation, 
testing  and  management/support.  Since  no  coding  is  going  on 
during  these  stages  it  mafcss  little  sense  to  include  them  in 
the  coding  effort.  Therefore,  that  would  imply  that  this 
measure  should  be  used  only  for  the  coding  phase.  Of 
coarse,  that  fccuses  attantion  on  the  coding  task  exclu- 
sively, which  is  a  minimal  portion  of  the  software 
development  effort. 

Finally,  this  measure  tends  to  penalize  high-order 
language  (HOL)  programs  in  favor  d f  programs  written  in 
Assembler  language.  Jones  [Ref.  29,  p.  21]  provided  the 
example  shown  in  Figure  I*.  1  .  This  is  an  example  of  the 
same  program  written  in  two  different  laguages.  Two  of  the 
purposes  of  using  HOL  ara  to  cut  costs  and  improve  produc- 
ti/ity.  But  the  example  shows  the  paradox  of  this  measure. 
It  appears  that  Assembler  language  is  more  productive  than 
the  HOL  even   though  the  HDL  program  took  one   nonth  less  to 


33 


, ^     _  — ________ 

Activity 

Assembler 
Language 

_. 
HOL 

Design 

Coding 

Testing 

Documentation 

Hgmt/Support 

^    weeks 

'4 

% 
2 
2 

4    weeks 

2 

2 

2 

2 

Tctal   Effort 

Lines    of   code 
LOC   per    prog-ison 

. _.            _            __ 

15    weeks 
(4    months) 

2300 

5  00 

12    weeks 
(3    months) 

500 

167 

Figure  4.1        Assembler  Language   vs   HOL. 

produce.  Notice  also  that  Jones  used  the  term  "programmer- 
month"  -co  mean  the  entire  program  development  time,  a  common 
practice,      as      mentioned    earlier.  The   actual      programming 

times  were  one  month  and  one-half  month  for  Assembler 
language  and  HOL r  respectively.  Even  if  this  time  frame  is 
used,  though,  the  Assembler  language  at  2000  LOC  per 
programmer-month  appears  to  be  twice  as  productive  as  the 
HOL  at  1000  LOC  per  programmer-month.  This  points  out  the 
problem    of      not    being  consistent      about    terms.  Jones   uses 

programmer-month  to  mean  the  entire  development  time  which 
yielded  an  average  productivity  figure  which  included  a 
period  when  no  ceding  was  being  done  at  all.  Using  the  term 
strictly  and  comparing  it  to  Jones'  usage  leaves  us  with  a 
four  tc  one  difference  in  productivity  for  Assembler 
language  and  a  six  to  one  difference  in  productivity  for  the 
HCL. 
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B.  MODULES    PER    MONTH 

This  particular  measure  was  presented  in  a  paper  by 
Crossman  [Ref.  23],  Surprisingly,  tiis  researcher  cculd  not 
find  any  other  references  that  have  attempted  to  duplicate 
his  findings.  Yet  he  pointed  to  several  advantages  which 
this  measure  and  its  methodology  of  program  development 
support. 

Modular  design  programming  tands  to  minimize  the 
complexity  of  projects.  minimizing  the  complexity  parameter 
allows  the  manager  to  reduce  the  number  of  variables  he  must 
consider  when  making  productivity  conparisons.  The  defini- 
tion of  a  module  appears  to  be  mors  consistent  throughout 
industry  than  LOC  which  gives  it  a  potentially  much  better 
coiparative  capability  between  organizations,  provided  the 
other  organizations  use  this  measure.  The  use  of  modules  as 
a  product  provides  a  consistency  throughout  the  development 
cycle.  It  includes  the  design,  coding,  testing,  docu- 
menting, and  management/support  phases.  Yet  it  can  also  ba 
broken  down  into  its  individual  component  efforts  to  deter- 
mine which  effort  has  the  greatest  impact  on  development 
time  and  the  impact  of  a ach  moduli  on  the  project  as  a 
whole. 

C.  FUNCTION  POINT  DELIVERED  PER  HOBS  HOUR 

Albrecht  [Ref.  27]  discussed  tha  effects  chis  approach 
has  on  showing  the  relative  productivities  between 
languages,  project  size  and  various  programming  technolo- 
gies. The  method  focusas  on  the  external  attributes  of  a 
program  and  the  work-hours  contributed  by  both  IBM  and 
customer  personnel  assigned  to  work  on  the  project.  It 
covers  all  phases  of  the  project.  The  goal  of  this  method 
of  measurement  i £  to  state  development  costs  in  terms  of  tha 
work-hours  used  to  design,  program  and  test  the  applications 
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project.  Although  thera  is  not  enough  data  available 
prasently  to  give  conclusive  results,  the  report  does  indi- 
cate the  capability  to  show  the  relative  productivities  of 
different  languages  and  development  technologies.  This  is  a 
major  advantage  that  is  not  possible  with  LOC  and  has  not 
yet  been  explored  using  modules. 

D.   SELECTED  IHDUSTRY  METHODS  FOR  MEASURING  PRODUCTIVITY 

The  preceding  sections  of  this  chapter  discussed  various 
methods  used  in  research  to  study  programmer  productivity. 
Each  method  mentioned  usas  a  ratio  of  outputs  (project, 
program,  specifications,  nodules,  LO:  or  function  value)  to 
inputs  (person-months,  pro  gram  mer-  m:>  nths,  or  work-hours). 
Previous  sections  provided  recommended  definitions  for 
selected  output  and  input  components.  This  section  presents 
measures  used  by  several  prominant  corporations  that  develop 
software. 

1.   IBM 


Measurement   of  programs   is  still   a  fairly   subjective 
process.    3e  can  measura  size-  basad  on  'lines  or  code1 


There 

is  a   veiled  invitation  aere   to  find   something  better. 
[  Ref.  30  ,p.  372] 


This  is  the  philosophy  used  to  approach  the 
measuring  of  programming  activities  at  the  Santa  Teresa 
Laboratory  of  IBM.  The  "something  better"  that  IBM  has  been 
trying  to  refine  for  the  Last  three  to  four  years  has  been 
the  software  science  metrics  developed  by  Halstead 
[Ref.  31].  Figure  4.2  slows  the  major  elements  in  use  by 
IBM  [Ref.  32]  [Ref.  30].    The  philosophy  for  using  software 
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Operands   =   values   that   are  change!    or    used   as    a 

reference   far    change    (constants,    variables 
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writina   code   and,    intuitively,    a 
measure    of    ease    of    reading. 

V,      N2 
-  T  *  7f2- 

Figure  4.2    Halstead  Blement  Relationships. 

science  metrics  is  built  on  the  following  beliefs.  First, 
in  any  given  language,  one  type  of  program  is  no  harder  to 
cede  than  another.  The  experience  at  Santa  Teresa  labora- 
tory over  the  last  five  years  is  that  the  only  things  that 
affect  productivity  are  the  language  and  the  tools  used. 
They  have  found  that  HOL  is  about  twice  as  productive  as 
Assembler  language.   Second,  aside  from  language,  the 
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development  -cools  are  what  affects  programmer  productivity. 
To  this  end,  IBM  has  consistently  added  to  the  "workbench" 
of  their  programmers^  They  have  provided  on-line  program- 
ming capabilities,  given  each  programmer  his/her  own 
terminal  in  his/her  office,  profiled  a  dedicated  program 
development  computer  aad  various  programming  aids  such  as 
Script.  Third,  the  definition  of  operators  and  operands  is 
consistent  across  language  barriers.  This  gives  software 
science  metrics  a  significant  advantage  over  other  measures. 
Additionally,  IBM  research  has  shown  that  the  size  metrics 
used  by  Halstead  are  as  accurate  as  LOC  for  measuring 
program  size. 

Since  programming  productivity  is  believed  to  be 
constant  for  all  programmers,  given  the  same  environment, 
IBM  has  looked  primarily  at  the  difficulty  metric. 
Difficulty  is  defined  as  a  metric  that  expresses  the  diffi- 
culty of  writing  code.  It  takes  into  consideration  decision 
nodes,  the  repertoire  of  operators  used  and  how  concise  the 
usage  cf  the  variables  is.  The  measure,  then,  also  appears 
to  be  one  for  ease  of  reading.  It  loss  not  tell  how  diffi- 
cult the  program  must  be.  It  only  tells  how  difficult  the 
programmer  made  the  program.  High  difficulty  can  come  from 
poor  programming  skills,  poor  program  structure,  inexperi- 
ence with  the  language  or  the  complexity  of  the  algorithm. 
The  value  of  this  metric  is  three  fold.  It  tends  to  indi- 
cate err or -pr oneness  much  earlier  in  the  development  cycle 
than  traditional  methods.  Intuitively,  the  n:re  difficult 
the  program,  the  more  error-prone  it  is.  The  measure  can 
only  be  taken  after  coding  has  been  completed  but  it  can  be 
calculated  immediately  fsLloving  the  first  clean  compile. 
There  is  no  need  to  wait  for  testing.  Secondly,  it  points 
out  these  programs  which  need  rework  due  to  high  difficulty 
values.  Third,  it  points  out  programmers  who  consistently 
have  high  difficulty   values.    This  enables  the   manager  to 
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ensure  that  the  programmer  receives  added  training  in  the 
technigues  available  to  reduce  program  difficulty.  IBM  has 
fojnd  that  the  difficulty  measure  tinds  to  range  frcm  three 
to  eight.  When  ever  they  see  thit  a  difficulty  measure 
exceeds  five,  they  call  the  programmer  in  to  have  him/her 
recode  the  program  to  reduce  the  difficulty  measure  to  five 
or  less.  If  the  programmer  consistently  delivers  code  with 
high  difficulty  measures  he/she  is  provided  aided  training 
in  technigues  which  can  lower  the  program  difficulty. 

All  this  only  gives  meisures  of  the  program  not  the 
prodcuctivity  of  the  programmer.  For  IBM  to  determine  that 
all  programmers  had  the  same  productivity,  they  had  to  test. 
The  test,  measure  was  and  continues,  on  a  minor  basis,  to  be 
L03  per  person-year.  L03  is  defined  as  data  declarations 
and  executable  statments.  The  use  of  this  measure,  now,  is 
only  to  check  for  changes  in  productivity  due  to  new  tools 
and  for  reasonable  production  rate  ralative  to  the  industry. 
I3M  recognizes  the  comparability  problem  of  the  LOC  measure. 
However,  the  IBM  perceived  industry  average  ranges  between 
800  and  2500  LOC  per  year,  given  the  line  counting  varia- 
tions. They  continue  to  measure  productivity  using  LOC  per 
man-year  to  ensure  that  IBS  remains  wihtin  this  range. 

2.   Amdahl 

a.      System    So  ft  wars 

Amdahl's  approach  to  systems  software  develop- 
ment is  different  from  most  of  the  industry.  As  a 
manufacturer  of  IBM  compatible  hardware  and  software,  their 
approach  is  to  use  IBM  software  proiucts  and  modify  them  to 
operate  more  efficiently  on  k mdahl  hardware.  This  means 
placing  "hooks1'  into  the  IBM  software  to  operate  special 
Amdahl  procedures.  Since  their  goal  is  develop  more  effi- 
cient  software,      these   hoots   must      be    minimal   in    both   length 
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and  interference  with  the  existing  software  and  logic. 
Amdahl  places  a  much  higher  empaasis  on  quality  than 
quantity. 

In  this  light,  none  of  the  previously  discussed 
measures  apply.  Amdahl  uses  a  management  by  objectives 
(M30)  approach  to  measure  performance.  Their  hiring  prac- 
tises aim  -cowards  acquiring  those  programmers  who  are 
experienced,  skilled  and  senior  in  the  industry.  The 
programmers  are  organized  into  groups  of  two  to  three 
assigned  to  one  -earn  leader.  Each  group  has  its  own  area  of 
responsibility  fcr  program  development/modification.  The 
assignment  of  tasks  and  the  time  constraints  are  determined 
by  mutual  agreement  between  the  manager  and  team  leader. 
The  schedules  are  recorded  and  eaoh  programmer  is  evaluated 
on  his/her  performance.  The  evaluation  is  discussed  with 
the  respective  programmer  at  the  periodic  performance 
review.  Since  each  group  has  specific  areas  of  responsi- 
bility and  thos€  areas  are  limited,  any  trouble  reports 
received  are  easily  assigned  to  -he  group  and/or  individual 
responsible.  These  are  also  included  in  the  performance 
review.  This  scenario  does  allow  any  specifio  measure  to 
quantify  programmer  performance.  However,  the  programming 
section  is  a  small  organization,  53-75  programmers,  so  they 
■crack  the  type  of  modification  against  the  time  required  and 
the  quality  of  the  programming.  Thiy  do  not  use  any  parti- 
cular measure  outside  of  budget  and  schedule.   [ Ref .  33] 

b.   Applications  Software 

Amdahl's  application  program  development  is  very 
siailar  to  the  systems  software  development  in  that  they  use 
M30  as  the  predominant  measure.  They  do  use  LOC  per 
programmer  year  to  do  some  measuring  but  it  has  very  little 
significance  to  the  operation.  LOC  is  defined  as  all 
programmer-original  COBOL  statments.   No  credit  is  given  for 
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reused  code,  although,  they  admit  some  credit  should  be 
given.  This  wculd  appear  to  discourage  reusing  code  but 
rhair  incentive,  reward  and  penalty  system  provides  the 
necessary  encouragement.  How  the  system  functions  was  not 
specified.  Management  does  require  programmers  to  use  data 
dictionaries,  and  code  libraries  are  kept  in  an  on-line  data 
base.  The  primary  measure  used  to  aeasure  performance  is  a 
review  of  the  programmer's  schedule.  The  programmer  submits 
a  schedule  of  task  accon?  lishment  to  the  manager.  The 
manager  reviews  it  to  ensure  it  is  realistic  and  then 
compares  the  schedule  to  the  task  completion  dates  as  the 
programmer  delivers  the  assigned  tasks.  Here,  as  in  systems 
development,  the  primary  ingredient  for  measuring  is 
programmer  and  manager  experience.   * Ref .  34] 

The  measure  used  to  evaluate  maintenance 
programming  is  built  aroui d  the  naaber  of  trouble  reports 
received.  Each  programming  group  is  responsible  for  mainte- 
nance of  its  assigned  software.  Teaa  leaders  must  emphasize 
high  quality  in  the  software  to  avoid  having  to  reschedule 
proarammers  onto  maintenance  from  development.  This  does 
not  prevent  errors  but  it  does  cut  them  down.  The  main 
emphasis  from  the  Applications  Programming  Manager  is  to 
ensure  as  rapid  a  response  time  as  possible  on  the  trouble 
reports.  The  required  turnaround  time  for  trouble  reports, 
presently,  is  not  to  exceed  six  montis.  They  use  the  turna- 
round measure  because  it  tends  to  indicate  to  the  users  that 
the  company  is  genuinely  interested  in  the  prcductivity  of 
software  maintenance.  It  also  gives  the  respective  managers 
an  additional  reason  when  requesting  more  resources. 
Finally,  it  gives  a  business  value  to  organized  maintenance 
because  it  forces  the  various  managers  to  schedule  resources 
for  program  maintenance. 
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Amdahl  uses  program  packages  predominantly  in 
thair  applications  programing  section.  These  packages  coma 
with  their  own  documentation  which  allows  Amdahl  to  take 
take  an  approach  significantly  different  from  this  research- 
er's view  point.  Amiahl  believes  program  code  and 
documentation  to  be  separate  and  uaegual  products.  This 
belief  is  made  possible  because  they  have  programs  that  can 
analyze  code  and  tell  the  programmer  the  structure  of  the 
code.  therefore,  they  feel  that  program  maintenance 
without  the  documentation  is  nor  as  difficult  one  might 
assume.  However,  documanation  is  sncouraged.  The  method 
used  is  to  reguest  documentation  ani  to  make  it  as  easy  to 
provide  as  possible.  To  make  the  dDcumentation  easier,  it 
is  all  written  on-line  using  Script  and  a  variety  of  user- 
developed  macros  that  provide  some  graphics  to  enhance  the 
prose.  The  documentation  guality  is  now  much  higher  and  the 
documentation  is  much  easier  for  the  programmers  to  deliver. 
[Raf.  34] 

3«   Systems  Development  Co:_p_orati  3_n  (SDC) 

SDC's  cost  estimating  procedures  use  LOC  and  pages 
of  documentation  as  fcha  primary  productivity  inputs  to 
compute  costs.  They  catagorize  tha  various  types  of  LOC 
(data  definitions,  executable  statements,  reused  code,  etc.) 
to  determine  the  subtask  cost  for  each  activity.  The  LOC 
are  weighted  by  an  in- house  conplexity  measure  which 
includes  parameters  for  program  siz  =  ,  security,  and  reli- 
ability. 2ach  productivity  measurs  is  computed  relative  to 
tha  type  of  program  (real-time  process  control,  interactive, 
report  generator,  data  basa  control,  etc.)  that  was 
produced.  Documentation  is  mesurai  by  pages  produced  per 
day  per  type  of  program.  Although  they  call  documentation  a 
separate  product,  they  consider  all  projects  to  be  inte- 
grated packages  of  both  software  code  and  documentation. 
[Raf.  35] 
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I.   TRW 

TRW  uses  a  weighted  LOC  per  man-month  method  to 
measure  productivity.  They  reviewed  Halstead^  metrics  but 
concluded,  as  did  IBM,  that  sourca  LOC  is  equivalent  to  the 
size  metrics  developed  from  counting  operators  and  operands* 
They  do  concede  that  ths  difficulty  metric  daserves  mora 
study  but  they  have  no  resources  ivialable  at  present  to 
conduct  such  a  study.  They  have  found  that  weighting  the 
LOC  with  an  in  house  factor  for  conplexity  and  reliability 
is  sufficient.  The  LOC  is  defined  as  a  delivered  well  docu- 
mented and  well  engineered  line  equal  to  a  card  image.  Tha 
card  image  is  an  eighty  character  Una.  Comment  lines  are 
not  included  but  all  lines  which  hoLd  "computing"  informa- 
tion are  (e.g.  job  control  language,  edit  links,  format 
statements,  data  declarations,  executable  statenents,  etc.). 
TRW  defines  a  man-month,  15  2  hours,  to  include  all  personnel 
hours  directly  chargeable  to  the  project. 

at  present,  TRW  does  not  measure  maintenance  produc- 
tivity. However,  the  interview  with  Dr.  Boehm  [Ref.  36], 
recommenced  the  method  discussed  in  his  book  Software 
Engineering,  Economics  [Ref.  37].  This  method  equates  the 
annual  maintenance  effort  to  the  aanial  change  traffic  (ACT) 
multiplied  by  the  estimated  development  effort.  ACT  is  the 
friction  of  the  software  product's  source  instructions  which 
undergo  change  during  a  typical  year,  either  through  addi- 
tion or  modification. 

TRW  includes  document  a -ion  in  its  definition  of  a 
LOC.  This  corresponds  with  the  philosophy  of  this 
researcher.  TRW  does  not  treat  software  code  and  documenta- 
tion as  separate  products  but  as  integral  parts  of  the 
software  project. 
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?.  CONCLUSIONS  AND  RECOMMENDATIONS 

This  paper  has  attempted  to  point  out  the  major  areas 
which  must  be  explored  in  order  to  measure  and  discuss 
programmer  productivity  or  software  development  produc- 
tivity. The  manager  Bust  decile  what  level  of  the 
organization  he  wishes  to  measure.  He  then  must  determine 
what,  specifically,  the  product  is  which  that  level  is 
making.  Before  proceeding  any  further,  he  should  examine 
the  quality  assurance  procedures  ana  practices  to  ensure 
that  they  are  both  in  use  and  that  they  do  establish  and 
check  for  a  minimum  quality  standard.  From  here  the  manager 
can  select  the  various  inputs  which  ie  feels  are  relevant  to 
stady.  The  productivity  rites  he  conputes  need  to  be  stored 
in  a  data  base  so  that  they  may  be  used  as  comparators 
against  time  and  other  organizations.  Finally,  each  measure 
must  be  kept  in  the  context  of  its  environment.  This  condi- 
tion provides  two  functions.  First,  it  keeps  the  measure 
meaningful.  Second,  by  selectively  ohanging  one  element  of 
tha  environment  at  a  time,  the  manager  can  determine  cause 
and  effect  relationships  that  can  lsad  to  establishing  the 
optimum  software  development  environnent . 

The  LOC  measures  are  poor  for  software  development  and 
lead  to  paradoxical  conclusions  in  many  instances. 
Regaining  with  any  measurs  that  uses  LOC  will  tend  to  bind 
tha  organization  to  technologies  requiring  the  development 
of  totally  original  code  nn  every  project.  This  will  tend 
to  prevent  the  use  of  metaprogramming  and  the  davelopraent  of 
program  families.  Thess  programning  technologies  show 
significant  promise  to  reduce  development  costs  and  improve 
programming  productivity  dramatically. 
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Modular  measures  provide  the  opportunity  to  explore  and 
develop  the  meta programniag  practice.  They  also  have  over- 
heads that  must  be  accepted  as  development  personnel  learn 
the  technology,  the  added  effort  required  in  the  design 
phase,  particularly  for  "small"  projects,  and  the  possible 
inefficient  use  of  CPU  tine  due  to  aa  increase  in  the  number 
of  LOC.  These  are  small  overheads  to  pay  if  the  development 
time  can  be  reduced  by  as  nuch  as  Laaergan  [Ref.  19]  claims. 
The  measure  can  be  used  in  conjunction  with  any  other 
measure  to  help  define  the  programming  activity  better.  It 
may  be  especially  usefal  in  conjunction  with  function 
points. 

In  closing,  it  is  apparent  for  the  literature  and  the 
discussions  with  the  selected  industry  corporations  that 
there  is  no  perfect  and  correct  measure  or  method  for 
measuring  programmer  productivity.  However,  the  vital  point 
to  understand  is  that  nearly  all  organizations  do  measure 
programmer  productivity  ia  som=  fashion.  Several  organiza- 
tions admit  that  their  methods  lack  some  possibly  important 
inputs  cr  parameters.  However,  each  organization  does 
attempt  to  measure  productivity  so  that  each  can  gain  some 
understanding  of  the  orgaa ization • s  particular  environment. 
With  an  understanding  of  the  environnent,  each  organization 
and  researcher  is  able  to  conceptualize  the  software  devel- 
opment process  so  that  tie  manager  can  make  intelligent 
assertions  about  how  it  is  affected. 
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APPENDIX    I 


or   SERVICES 

FUNCTION  VALUE  INDEX  WORKSHEET 


Data  i 


•roject  10 1_ 


Project  aamai 
Prepared  byi 


Datai 


Reviewed  by i 


Data: 


Project  Sunmuy:    Start  Date 


:.i:  Date 


work-Hours 


function  Points  Selivcrcd  or  Designed 
i  (from  calculation). 


Function  Points  Calculation  (Delivered  or  Sjsicned) 


r 


Allocation  estimated  by  Project  Manager 


Not*:    Definitions 
on  back  of  form. 

Delivered 
by  New 
Coda 

Delivered 
by  Modifying 

Existing 
Code 

Delivered  by 
Installing 
and  Testing 
a  Package 

Delivered 
by  Using 
a  Code 

Generator 

Totals 
(Identify 

Preponderant 

Language) 

Language 

Inputs 





X   4 

Outputs 

X   5  ~ 

riles 

X  10 

Inquiries 

X   « 

Work-hours 

total 

Design 
Implementation 


Unadjusted 

Function 

Points 


Complexity  Id'uit-.ent: 


(Estimate  degree  of  influence  for  each  factor) 


■•11»M»  b»cku".  recovery,  and/or 
system  availability  are  provided 
by  the  application  design  or 
Implementation.   The  Junctions 
may  be  provided  by  specifically 
designed  application  code  or  by 
use  of  functions  provided  by 
standard  software.   Tor  example, 
the  standard  IMS  backup  and 
recovery  functions. 

Data  communications  are  provided 
in  the  application. 

Distributed  processing  function* 
are  provided  in  the  application. 

Performance  must  be  considered 
in  the  design  or  implementation. 

In  addition  to  considering 
performance  there  is  the  added 
complexity  of  a  heavily  utilized 
operational  configuration.   Th* 
customer  wants  to  run  the 
application  on  existing  or 
committed  hardware  that,  a*  a 
consequence,  will  be  heavily 
utilized. 


On-line  data  entry  is  provided  in 
the  *p|>lic«nuii. 

On-line  data  entry  is  provided  in 
the  application  and  in  addition 
the  data  entry  is  conversational 
requiring  that  an  input  trans- 
action be  built  up  over  multiple 
operations. 

Master  files  are  updated  on-line. 


Inputs,  outputs,  files,  or 
Inquiries  are      complex  in 
this  application. 


Internal  processing  is 
In  this  application. 


complex 


Degree   of    Influence   on   Function: 

0  None  3    Average 

1  Incidental    <    Significant 

2  Moderate     S   Essential 


Total  Degree  of  Influence  (N) 

Complexity  adjustment  equals  (0.7S  ♦  O.OI  (Nl) 

Unadjusted  Total  X  Complexity  Adjustment  «  Function  Toints  Delivered  or  Designed 
X  -     
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neflnltionsi 


Ccfifnl  Instruction: 


Count  all  inputs,  outputs,  sister  files, 
inquiries,  and  (unctions  that  are  Bade  available 
to  the  cuitoecr  through  the  project's  desiqn, 
programming,  or  testinq  efforts.   For  example, 
count  the  functions  provided  by  an  IUP,  FOP,  or 
Program  product  if  the  package  was  modified. 
Integrated,  tested,  and  thus  provided  to  the 
customer  through  the  project's  efforts. 


Work-hours: 

The  work-hours  recorded  should  be  the  IBM  and 
custoaer  hours  spent  on  the  OP  Services 
standard  tasks  applicable  to  the  project  phase 
The  customer  hours  should  be  adjusted  to  IBM 
equivalent  hours  considering  experience, 
training,  and  work  effectiveness. 


Input.  Count: 

Count  each  systea  input  that  provides  business 
function  cossnunication  from  the  users  to  ths 
computer  system    For  example: 

•  data  forms         •  scanner  forms  or  cards 

•  terminal  »cr«ens    a  key<cu  transactions 

Do  not  double  count  the  inputs.   For  example, 
consider  a  manual  operation  that  takes  data 
froo  an  input  :ora,  to  form  two  input  screens, 
using  a  keyboard  to  form  each  screen  before  the 
entry  key  is  pressed.   This  snould  be  counted 
as  two  (2)  inputs  not  five  (5). 

Count  all  unique  Inputs.   An  input  transaction 
should  be  counted  as  unique  if  it  required 
different  processing  logic  than  other  inputs. 
For  example,  transactions  such  as  add.  delete, 
or  chanqe  may  have  exactly  the  same  screen 
format  but  they  should  be  counted  as  unique 
Inputs  if  they  require  different  processing 
logic. 

Do  not  count  input  or  output  terminal  screens  that 
are  needed  by  the  system  only  because  of  the 
specific  tecr.nical  implementation  of  the 
function.   For  example,  DMS/VS  screens,  that 
are  provided  only  to  get  to  the  next  screen 
and  do  not  provide  a  business  function  for  the 
user,  should  not  be  counted. 

Do  not  count  input  and  output  tape  and  file  data 
sets.   These  are  included  in  the  count  of  files. 


Output   Count i 

Count  each  system  output  that  provides  business 
function  communication  from  the  computer  system 
to  the  users.   For  example : 


a  printed  reports 
•  terminal  screens 


•  terminal  printed  output 

•  operator  messages 


Count  all  unique  external  outputs.   An  output  is 
considered  to  be  unique  if  it  has  a  format 
that  differs  from  other  external  outputs  and 
Inputs,  or,  if  it  requires  unique  processing 
logic  to  provide  or  calculate  the  output  data. 

Do  not  include  output  terminal  screens  that 
provide  only  a  simple  error  message  or 
acknowledgement  of  the  entry  transaction, 
unless  significant  unique  processing  logic 
is  required  in  addition  to  the  editing 
associated  with  the  input,  which  was  counted. 


Do  not  include  on-line  inquiry  transaction 
outputs  where  the  response  occurs  immediately. 
These  are  included  in  a  later  question. 


File  Count: 

Count  each  unique  machine  readable  logical 
file,  or  logical  grouping  of  data  from  the 
viewpoint  of  the  user ,  that  is  generated, 
used,  or  maintained  by  the  system.   For 
example : 


Do  not  count  inquiry  transactions. 
covered  in  a  subsequent  question. 


These  are 


input  card  files 
disk  files 


tape  files 


Count  major  user  data  groups  within  a  data  base. 
Count  logical  files,  not  pnysical  data  sets. 
For  example,  a  customer  file  requiring  a 
separate  index  file  because  of  the  access 
method  would  be  counted  as  one   logical 
file  not  two.   However,  an  alphabetical 
index  file  to  aid  in  establishing  customer 
identity  would  be  counted. 

Count  all  machine  readable  interfaces 
to  other  system  as  files. 


Inquiry  Count: 

Count  each  input/response  couplet  where  an  on- 
line input  generates  and  directly  causes  an 
immediate  on-line  output.   Data  is  not  entered 
except  for  control  purposes  and  therefore  only 
transaction  logs  are  altered. 

Count  each  uniquely  formatted  or  uniquely 
processed  inquiry  which  results  in  a  file  score: 
for  specific  information  or  summaries  to  be 
presented  as  response  to  that  inquiry. 

Do  not  also  count  inquiries  as  inputs  or 
outputs. 
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APPENDIX  II 


DP  SERVICES  DESIGN  PHASE 

SIZE  AND  COMPLEXITY  FACTOR  ESTIMATOR  FORM 


Section  6.2 
12-31-78 


Customer: 


Project  Description: 


Project  ID:. 


Prepared  By; 


When  Prepared:   (check  one  block) 

(  )  Before  any  Phase  Completion 

(  )  Requirements  Complete 

(  )  External  System  Design  Complete 

(  )  Internal  System  Design  Complete 


Date  Prepared: 


(  )  Coding  Specs  Complete 

(  )  Integration  Complete 

(  )  System  Test  Complete 

(  )  System  Demo  Complete 


DESIGN  PHASE 
SIZE  AND  COMPLEXITY 
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QUESTION  DEFINITIONS 


1.  SCOPE  OF  THE  INVOLVEMENT  WITHIN  THE  COMPANY 

a.  Company  Functional  Organizations: 

Identify  the  number  of  independent  organizational  entities  which 
will  be  involved  either  directly  or  indirectly  in  the  project 
For  example,  if  the  system  includes  two  business  functions 
inventory  control  and  billing,  at  least  two  organizations 
probably  would  be  involved.   Direct  involvement  refers  to  actual 
participation  in  the  requirement  study  or  design.   Indirect 
involvement  refers  to  review  and  approval  of  the  requirements  or 
design.   The  organizations  may  be  counted  separately  in  each 
location.   For  example,  if  the  accounting  department  has  a 
subdepartment  in  each  of  three  geographic  locations ,  and  if  each 
must  either  be  interviewed  or  included  in  the  approval  cycle, 
then  the  accounting  function  should  be  counted  as  three 
organizations  rather  than  one.   Always  include  the  data 
processing  organization. 

b.  Company  Locations: 

Identify  the  number  of  company  locations  that  require  travel  for 
information,  interviews  or  approvals.  The  primary  location  must 
also  be  counted.  Each  city  involved  would  be  a  location.  Where 
multiple  locations  exist  in  the  same  city,  consider  each  as  half 
a  location. 

c.  Number  of  people  in  the  organizations  involved: 

Identify  the  number  of  hundreds  of  people  in  each  organization 
identified  in  question  la)  above.   For  example,  a  project 
involving  two  organizations,  one  with  135  people,  and  one  with  50 
people  would  count  as  three  hundreds  of  people.   This  provides  a 
definition  of  complexity  of  interviews  and  requirements 
definition. 

2.  FUNCTIONAL  SIZE  OF  THE  APPLICATION 
a.   Number  of  Major  Subsystems: 
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SCOPE  OF  THE  INVOLVEMENT  WITH  THE  COMPANY 


Number  of  company  functional 

organizations  involved:         x  1  =_ 


Number  of  company  locations 

involved:  x  12  = 


c.   Number  of  100  (s)  of  people  in 

the  involved  organizations:     x  2  =_ 


Fl 
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In  general,  a  major  subsystem  is  equivalent  to  a  major 
application  or  system  function.   Examples  of  subsystems  within  an 
Order  Processing  System  might  be: 

Order  Entry 

Accounts  Receivable 

Inventory  Update 

Inventory  Replenishment 

Shipping 

Recovery  and  Restart 

Invoicing 

Management  Reporting 

File  Administration 

File  Conversion 


If  you  think  that  a  function  is  logically  separable  and 
reasonably  significant  in  size  then  count  it  as  a  subsystem. 


Number  of  External  Inputs: 

This  question  addresses  all  system  input  vehicles 
business  function  communication  from  the  users  to 
system  (e.g.,  data  forms,  terminal  screens,  keyboa 
transactions,  optical  scanner  forms).   It  does  not 
internal  inputs  such  as  tape  and  file  data  sets, 
included  in  the  count  of  files.   It  should  not  inc 
screens  that  are  needed  by  the  design  only  because 
specific  implementation  (e.g.,  DMS/VS  screens  that 
provided  to  get  to  the  next  screen  but  do  not  prov 
business  function  or  business  information  for  the 


that  provide 
the  computer 
rd 

include 
These  are 
lude  input 

of  the 

are  only 
ide  input  of  a 
terminal  user.) 


It  should  include  the  inputs  associated  with  all  the  functions 
committed  in  the  design.   If  such  functions  as  File  Conversion 
and  Data  Base  Maintenance  are  to  be  supported  their  inputs  must 
be  counted  even  if  they  are  used  only  once. 

On-line  inquiry  transactions  should  not  be  counted  here  since 
they  are  included  separately  in  a  later  question. 

The  obj active  of  this  question  is  to  enumerate  all  unique  inputs. 
An  input  transaction  should  be  counted  as  unique  if  there  is  any 
possibility  that  it  will  require  different  processing  logic  than 
other  transactions.   For  example,  transactions  which  have  exactly 
the  same  screen  format  and  differ  only  in  a  code  used  to  indicate 
transaction  type  (e.g.,  add,  delete,  change)  should  each  be 
counted  separately  as  unique  transactions - 

c.   Number  of  External  Outputs: 
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2.  FUNCTIONAL  SIZE  OF  THE  APPLICATION 


a.   Number  of  Major  Subsystems:     xlO  ■ 
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As  with  the  External  Inputs  this  question  addresses  all  system 
output  vehicles  that  provide  business  function  communication  from 
the  computer  system  to  the  users  (e.g.,  printed  reports,  output 
screens,  hard  copy  terminal  output  operator  messages).   On-line 
inquiry  transactions,  where  the  response  occurs  immediately  on- 
line should  not  be  included  in  this  count.   However,  printed 
reports  which  are  triggered  by  off-line  or  on-line  inquiries 
should  be  included  in  this  count.   The  count  should  not  inlcude 
output  screens  that  are  needed  by  the  design  only  because  of  the 
specific  implementation  (e.g.,  DMS/VS  screens  that  are  only 
provided  to  get  to  the  next  screen  but  do  not  provide  a  business 
function  or  business  information  for  the  terminal  user.) 

An  output  is  considered  to  be  unique  if  it  has  its  own  format 
which  differs  from  other  external  outputs,  or  if  it  requires 
unique  processing  logic  to  provide  or  calculate  the  output  data. 

d.  Number  of  Files: 

This  count  should  include  each  planned  unique  machine  readable 
logical  file,  or  logical  grouping  from  the  viewpoint  of  the  user, 
that  is  to  be  generated  by  or  input  to  the  system  (e.g.,  card 
types,  data  base  files,  disk  files,  tape  files).   This  question 
is  oriented  toward  logical  files  not  physical  data  sets.   For 
example,  a  customer  file  requiring  a  separate  index  file  because 
of  the  access  method  chosen  during  design  would  be  counted  as  1 
logical  file  not  2.   However,  a  special  alphabetical  index  file 
to  aid  in  establishing  customer  identity  would  be  counted 
separately. 

This  count  should  include  all  machine  readable  interfaces  to 
other  computer  systems. 

e.  Number  of  On-line  Inquiry  types: 

This  question  addresses  conversational  input/response  couplets 
where  the  on-line  input  generates  and  directly  causes  an 
immediate  on-line  output.   These  couplets  generally  do  not  enter 
data  except  for  control  purposes  and  therefore  alter  only 
transaction  logs. 

In  determining  this  count  consider  each  uniquely  formatted  or 
uniquely  processed  inquiry  (input/response  pair)  which  results  in 
a  file  search  for  specific  information  or  summaries  of  groups  of 
information  to  be  presented  as  output  response  to  that  inquiry. 

Inquiries  should  not  also  be  counted  as  inputs  or  outputs. 
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c.   Number  of  external  Outputs:         x  3  =_ 
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d.   Number  of  Files:  x  7  = 


e.   Number  of  On- Line  Inquiry  Types:    x  4  =_ 


F2 
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3.  COMPLEXITY  OF  THE  OVERALL  DESIGN  PHASE 

a.  Customer  Capability: 

Consider  whether  the  customer  has  data  processing  or  user 
capability  that  will  provide  a  good  environment  for  requirements 
definition  and  system  design  or  whether  his  people  will  require 
more  that  normal  explanation  and  justification  for  routine 
decisions. 

On  the  other  hand  does  the  customer  have  so  much  expertise  that 
his  design  convictions  will  complicate  the  job  beyond  that 
normally  expected.   (e.g.,  an  application  well  suited  to  IMS  but 
the  customer  wants  to  develop  his  own  TCAM  data  base  system. ) 

Both  situations  would  hinder  the  project. 

b.  Existing  Customer  Function: 

Does  the  customer  currently  perform  the  business  functions  that 
are  to  be  included  in  the  system  or  is  this  a  new  business  area? 

An  example  of  a  new  function  that  would  result  in  a  "no"  answer 
would  be,  an  insurance  company  that  does  not  currently  handle 
group  dental  plans  but  wants  to  develop  an  automated  system  to 
process  group  dental  claims  so  that  they  can  compete  for  that 
type  of  business. 

c.  Existing  EDP  System: 

If  the  answer  to  the  previous  question  was  No,  then  this  question 
must  also  be  answered  No.   If  the  customer  currently  is 
performing  the  majority  of  the  business  functions  to  be  included 
in  the  system  and  a  significant  number  of  these  are  being 
supported  by  existing  EDP  System(s),  the  answer  should  be  Yes. 
Otherwise,  the  answer  is  No. 

d.  First  of  a  Kind: 

Has  this  application  ever  been  computerized  before,  anywhere?   Is 
this  the  first  attempt  to  automate  a  significant  business 
function  in  the  application?   A  Yes  to  either  question  should 
make  this  system  the  First  of  a  Kind. 

e.  Hardware  and  Software  Operational  Environment: 

This  question  is  addressing  the  overall  complexity  of  the 
estimated  operational  system.   An  example  of  a  Simple  system 
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3.  COMPLEXITY  OF  OVERALL  DESIGN  PHASE 


a.   Will  the  customer's  capability  hinder: 
No  (0),  Yes  (10) 


b.   Existing  customer  function  to 
be  automated: 
No  (10),  Yes  (0) 


Does  an  EDP  system  exist  now 
to  perform  the  function: 
No  (6),  Yes  (0) 


Is  this  system  the  first  of  its 
kind  anywhere: 
No  (0),  Yes  (10) 
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environment  would  be  S/370  Models  115  or  125,  DOS  or  DOS/VS  and 
the  IBM  Standard  TP  and  data  base  products  that  operate  on  that 
level  CPU. 

An  example  of  an  In  Between  system  environment  would  be  S/370 
models  135  or  1U5,  DOSr  DOS/VS  or  OS/VS  and  CICS  or  DL/I  or 
something  equivalent. 

Large  computers  or  more  sophisticated  operating  System  (e.g. , 
MVS)  or  TP  or  DB  environment  (e.g.,  IMS  or  TCAM)  would  be 
considered  as  Complex.   Distributed  processing  and  programmable 
terminals  would  also  be  considered  complex. 

4.  SOPHISTICATION  EXPECTED  OF  THE  SYSTEM 

a.  In  answering  the  availability  question  consider  how  important  it 
is  that  the  system  be  kept  available  to  the  users.   The  whole 
data  processing  system  including  communications  and  terminals 
should  be  considered.   Can  work  be  postponed? 

Will  components  be  duplicated  to  increase  system  availability? 
This  can  indicate  critical  availability.   Will  the  system  be 
designed  to  recover  quickly  from  failure?  This  can  indicate 
important  availability. 

A  batch  system  usually  requires  normal  availability.   A  data 
collection  system  with  non-perishable  inputs,  such  as  paper  claim 
forms,  might  justify  important  availability.   A  passenger 
reservation  system  or  bank  funds  transfer  system  might  require 
critical  availability. 

b.  Will  a  major  or  important  design  consideration  be,  that  each 
operation  or  function  identified  as  critical  have  an  alternate 
method.   The  alternate  may  involve  manual  operations  and  may  take 
longer  but  the  function  is  provided. 

c.  Will  the  system  contain  data  that  must  be  protected  against  loss? 
Will  the  function  require  special  recovery  design  in  either 
procedures  or  system?  If  so,  the  answer  is  yes. 

d.  Data  Traffic  Load  or  System  Performance: 

In  some  systems,  the  volume  of  data  to  be  handled  is  not  a  design 
concern.   Other  systems  require  special  design  considerations 
such  as:  use  of  file  access  optimization,  simplified  input 
notation,  or  extensive  use  of  exception  reporting.   Transaction 
rates  may  be  a  problem  in  either  on-line  or  batch  systems.   Large 
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Hardware  and  software  system 
operational  environment  to  be 
required  by  the  application: 
Simple  (0),  In-between  (5),  Complex  (10) 


F3 


a.  SOPHISTICATION  EXPECTED  OF  THE  SYSTEM 

a.  Availability  is:   Critical  (8), 
Important  (U),  Normal  (0) 

b.  Is  an  alternate  method,  for 
performing  the  functions  of  the 
system,  non-routine  consideration: 
No  (0),  Yes  (6) 

c.  Is  system  recovery  or  protection 
against  data  loss  a  non-routine 
consideration: 

No  (0) ,  Yes  (5) 
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volumes  of  data  in  short  periods  (peak  loads)  or  volumes  of  data 
large  enough  to  cause  machine  availability  problems  are  all 
considered  data  traffic  considerations. 

System  performance  is  often  a  significant  design  consideration  in 
systems  that  are  intended  to  handle  large  volumes  of  data.   It 
can  also  be  of  major  concern  in  the  design  of  systems  with 
relatively  low  transaction  rates  but  with  constraints  (perhaps 
economic)  in  terms  of  the  prescribed  hardware  and  software 
environment.   For  example,  there  may  be  limitations  on  the  size 
of  main  storage,  control  program  multi -programming  capabilities, 
or  transmission  line  speeds. 

e.  Nature  of  the  Application: 

A  batch  system  operates  as  a  job  shop,  often  scheduled. 
Transactions  are  typically  batched  external  to  the  computer  and 
periodically  processed  sequentially  against  the  master  files. 

An  on-line  system  generally  requires  a  more  sophisticated 
man/ machine  interface  than  a  batch  system.   It  is  generally  a 
system  where  transactions  are  entered  as  they"  are  received  rfith 
no  opportunity  for  time  saving  sorting.   The  inputs  are  not 
perishable  (i.e.,  they  can  be  re-entered  if  necessary).   An  on- 
line order  entry  system,  or  an  on-line  stock  location  and 
inventory  control  system  would  be  examples  of  on-line. 

A  real-time  system  is  similar  to  an  on-line  system  in  that  it  is 
available  on  demand,  but  it  has  an  additional  requirement  to  not 
postpone  its  main  line  processing.   Response  time  is 
exceptionally  important.   Immediate  processing  and  response  is 
necessary  to  meet  the  functional  requirements  of  the  system. 
Process  control,  production  test  stand  control,  and  airline 
reservation  systems  are  examples  of  real-time  systems  where 
degraded  performance  may  cause  lost  production  or  lost  business. 

f.  Processing  Complexity: 

This  question  addresses  the  internal  processing  logic  required  to 
provide  the  majority  of  the  proposed  system  functions. 
Straightforward  logic  would  involve  simple  transformations  or 
mapping  from  the  system  inputs  or  files  to  the  system  outputs. 
For  example,  a  transaction  is  read,  verified  to  a  limited  degree 
and  used  to  update  a  simple  master  file  or  to  generate  a  simple 
report.   Processing  is  a  straightforward  set  of  pre-specif ied 
rules.   Few,  if  any,  data  transformations  are  done.   Outputs  are 
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d.   Is  data  traffic  load  or  system 
performance  an  important 
design  consideration: 
No  (0),  Either  (10),  Both  (20) 


e.   Nature  of  the  Application: 

Batch  (0),  On-Line  (10),  Real-Time  (20) 
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mostly  collections  in  various  sets,  of  established  data  from 
files. 

Complex  should  be  checked  if  the  system  has  a  preponderance  of 
exception  processing  resulting  in  many  incomplete  transactions 
that  must  be  resolved  later  or  again.   Complex  logic  would  also 
be  the  answer  if  there  are  many  interactions  and  decision  points 
and  extensive  logical  or  mathematical  equations.   In-between  is 
used  if  it  fails  to  meet  either  of  the  above  definitions. 

g.   Exception  Correction: 

Systems  which  are  designed  primarily  to  process  correct  data  and 
to  detect  and  present  bad  or  unusual  data  for  manual  review  and 
correction  are  manual  exception  systems.   If  the  system  is  to  be 
designed  not  only  to  detect,  but  also,  automatically  to  correct  a 
significant  number  of  unusual  conditions,  the  system  is  an 
automatic  exception  system.   This  is  true  even  if  the  options 
selected  or  corrections  applied  are  to  be  reviewed  and  verified 
manually. 

5.  KNOWLEDGE  WE  HAVE  FOR  THIS  PROJECT 

a.  Consider  the  Services  Area  in  general  and  specifically  the  people 
who  may  influence  the  project  through: 

•  Project  Management 

•  Proposal  Preparation 

•  Systems  Assurance 

•  Project  Team  Performance 

Consider  the  Area's  current  knowledge  and  the  available  Industry 
knowledge-   If  none  of  the  people  in  the  performing  Area  have 
designed  or  implemented  this  type  of  application  before,  the 
answer  should  be  Completely  New.   If  informed  consultation  and 
review  is  available  with  people  in  the  Area  the  answer  should  be 
Some  Familiarity.   If  Services  people,  clearly  expected  to 
participate  significantly  in  the  proposal  and  project,  are 
currently  assigned  to  the  performing  Area  and  have  recently 
performed  on  a  similar  project  the  answer  may  be  Have  Done 
Similar  Job  Once. 

b.  To  answer  Extremely  Thorough  the  proposal  should  contain  a 
technical  baseline  that  shows  excellent  understanding  of  the 
tasks  in  the  Statement  of  Work.   The  Customer  User,  IBM  Branch, 
and  DP  Services  must  have  contributed  and  concurred  with  the 
approach.   Everything  else  should  be  moderate  unless  we  lack 
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511 


Processing  complexity: 

Straightforward  (0), 

Complex  (30),  In-between  (15) 


Exception  Correction  is  mostly: 
Manual  (0),  Automatic  (20) 


F<» 


5.  KNOWLEDGE  WE  HAVE  FOR  THIS  PROJECT 

a.   How  familiar  is  the  proposed 

Services  Area  with  this  Application: 
Completely  New  (30),  Some 
Familiarity  (15)  ,  Have  done 
Similar  job  once  (0) 
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customer  agreement  either  through  lack  of  contact  or  because  of 
direct  disagreement. 

6.  READINESS  TO  PERFORM  THIS  PROJECT 

a.  Consider  the  location  of  the  project  with  respect  to  the  home 
location  of  the  people  expected  to  work  on  it.   Unless  local 
commuting  habits  and  ground  rules  indicate  otherwise,  travel  of 
more  than  one  hour  each  way  to  the  work  location  should  be 
considered  Significant  Commuting. 

b.  Consider  the  proposed  manning  on  the  project.   Normally  the 
manning  on  DP  Services  projects  comes  from  DP  Services,  the  IBM 
Branch,  or  the  Customer.   If  the  manning  is  proposed  with 
elements  other  than  these,  (i.e.,  subcontract  or  shop  order)  mark 
an  equivalent  answer  from  the  viewpoints  of  Project  Management 
control  and  the  resource's  ability. 

c.  All  temporary  or  permanent  moves  of  project  team  members  should 
be  considered  whether  they  involve  IBM  people  or  customer  people. 

THE  SIZE  AND  COMPLEXITY  FACTOR  COMPUTATION: 

To  compute  the  Design  Phase  Size  and  Complexity  Factor  that  will  be  used 
to  validate  the  task-by-task  estimate  follow  these  steps: 

1.  Review  and  sum  up  the  weighted  answers  to  the  questions  to 
determine  factors  Fl  through  F6. 

2.  Enter  Fl  through  F6  and  evaluate  the  equations  on  page  19. 

3.  Sum  the  results  of  (1),  (2)  and  (3)  to  obtain  the  Design  Phase 
Size  and  Complexity  Factor. 

ESTIMATE  VALIDATION: 

Use  the  Design  Phase  Size  and  Complexity  Factor  and  the  plots  provided 
in  Section  6.2  to  determine  the  average  number  of  hours  that  the 
standard  tasks  took  on  completed  DP  Services  projects  with  similar 
Design  Phase  Size  and  Complexity  Factors.   Enter  these  hours  in  the 
appropriate  blanks  on  page  20. 

If  the  data  is  sparse,  the  information  on  each  standard  task  may  not  be 
provided  as  a  separate  number.   However,  the  hours  spent  on  that  task 
are  in  the  totals  and  in  the  associated  standard  task.   (e.g. ,  the  hours 
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b.   Services  Preproposal  Analysis: 
Extremely  thorough  (0), 

Moderate  (10),  No  customer  agreement  with 
approach  (20) 


F5 


6.  READINESS  TO  PERFORM  THIS  PROJECT 

a.  Where  is  project  to  be  located: 
No  unusual  commuting  (0) , 
Significant  Commuting  (5), 
Temporary  or  permanent  moves 
required  (10) 

b.  Manning: 

All  Services  (0),  Mixed  IBM  Manning  (5), 
Customer  and  IBM  Mixed  (10) 
c-   Number  of  temporary  and  permanent 
moves  required 

x  5  = 


F6 


75 


DP  SERVICES  DESIGN  PHASE  Section  6.2 

SIZE  AND  COMPLEXITY  FACTOR  ESTIMATOR  FORM  12-31-78 

for  implementation  planning  may  not  be  separately  identified,  but  they 
would  be  in  the  internal  system  design  task  and  in  the  total  hours.) 

Map  the  task-by-task  estimate  into  the  same  standard  tasks  and  compare 
the  estimates.   The  Proposal  Manager  should  analyze  and  explain  any 
differences  or  make  the  appropriate  adjustments  in  the  task-by-task 
estimate  and  the  proposal. 

FEEDBACK  PROJECT  RESULTS: 

After  the  project  is  completed  and  the  PCAR  is  available,  adjust  the 
Design  Phase  Size  and  complexity  Factor.   The  factor  needs  to  be 
adjusted  to  account  for  changes  (approved  PCR(s))  that  occurred  during 
the  project.   This  adjustment  provides  a  factor  that  should  be  related 
to  the  completed  project's  results: 

Original  S  S  C  -    The  original  size  and  complexity  factor  computed 

at  proposal  time  on  page  19. 

Change  Hours   -    The  total  estimated  hours  of  approved  changes 

taken  from  the  PCAR. 

Total  Hours 

Multiplier     -    The  current  factor  multiplier  for  the  total 

hours  plot  in  the  design  phase  estimator. 

Adjusted  S  &  C  -    The  size  and  complexity  factor  used  for  project 

feedback  of  results  adjusted  for  the  approved 
changes. 

Adjusted  S  C  C  =    Change  Hour 3    ♦  Original  S  &  C 

Total  Hours  Multiplier 

The  results  of  the  completed  project  standard  tasks  and  the  delivered 
reports  are  also  taken  from  the  PCAR.   If  the  project  does  not  represent 
a  complete  design  phase,  the  numbers  must  be  used  with  care.   (e.g.,  a 
requirements  only  design  phase  can  give  a  good  requirements  number.   It 
certainly  won't  give  any  design  numbers.   Less  obviously,  it  won't  give 
any  management  numbers  or  total  hours  numbers  either) . 
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SIZE  AND  COMPLEXITY  FACTOR  ESTIMATOR  FORM  12-31-78 

THE  SIZE  AND  COMPLEXITY  FACTOR  COMPOTATION: 

1.  Orientation  Factor: 

( )  (100  ♦  ( )  ♦  ( ))  x  .9/1000  =  

Fl  F5  F6 

2.  Requirements  Analysis  Factor: 

( )  (100  ♦  ( 

F2 

♦  ( )/10  ♦  ( )  ♦  ( 

Fa  F5  F6 

3.  System  Design  Factor: 

)/3 


) 

♦ 

( 

) 

Fl 

F3 

)/10 

♦ 

( 

) 

♦ 

( 

( 

F2 

)  (100  ♦ 

( 

F3 

)/2  ♦ 

( 
FU 

♦  ( 

F5 

)/4> 

1.7/1000 

= 

Size 

and  Complexity  Factor  = 

Sum(l),(2),(3) 
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ESTIMATE  VALIDATION: 

Total  Hours 

System  Design 

External  System  Design 
Internal  System  Design 
Implementation  Plan 

Requirements  Definition 

Orientation 

Management 

System  Design  Report  Size 

Requirements  Report  Size 


From  From 

S  fc  C  Factor    Task-By-Task    Comments 
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FEEDBACK  OF  RESOXTS: 

Adjust  Size  and  Complexity  Factor:         By: Date: 


( )  ♦  ( )  =  ( >    Adjusted  Size  and  Complexity 

( )  Factor 

Completed  Project  Results:  By: Date: 

Total  Hours  

System  Design  

External  System  Design'       

Internal  System  Design        

Implementation  Plan  

Requirements  Definition        

Orientation  

Management  

System  Design  Report  Size      

Requirements  Report  Size       
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